Ereeform Search 



Page 1 of 2 



Freeform Search 



I us Pre-Grant Publication Full-Text Database" 



Database: 



Term: 



US Patents Full-Text Database 



US OCR Full-Text Database 
EPO Abstracts Database 
JPO Abstracts Database 
Derwent World Patents Index 
IBM Technical Disclosure Bulletins 



L17 and prefix$ 



jd 



Display: |10 | Documents in Display Format : |KW1C | Starting with Number |l 



Generate: O Hit List ® Hit Count C Side by Side O Image 



Search History 



DATE: Wednesday, February 16, 2005 Printable Copy Create Case 

Set Name Query Hit Count Set Name 



side by side 




result set 


DB= 


USPT; PLUR=YES; OP=ADJ 






L26 


L17 and prefix$ 


1 


L26 


L25 


LI 9 and (prefix$ with (compar$ or updat$ or replac$ or chang$)) 


1 


L25 


L24 


LI 9 andprefix$ 


1 


L24 


L23 


L19 compar$ 


0 


L23 


L22 


LI 9 and (PTSE with (updat$ or changS or replacS)) 


1 


L22 


L21 


L20 and (PTSE with (updat$ or changS or replac$)) 


1 


L21 


L20 


L19 and PTSE ^ ' » 
6208623.pn.-=- ^^^aA^\ 


1 


L20 


L19 


1 


L19 


L18 


L17 and PTSE 


2 


L18 


L17 


(6606303 or 6243384 or 6208623 or 6002674).pn. 


4 


L17 


L16 


L7 and ((replac$ or changS or updat$) adj3 prefix) 


0 


L16 


L15 


L7 and prefix 


16 


L15 


L14 


L7 and (chang$ adj3 address$) 


6 


L14 


L13 


L7 and (chang$ with addressS) 


14 


L13 


L12 


L7 and ((replac$ or changS or updat$) with address$) 


20 


L12 


Lll 


L7 and SIG 


5 


Lll 



h eb bgeee e bch f ff e ch 



Freeform Search 



Page 2 of 2 



LIO 


L7 and SIG 


5 


LIO 


T /\ 

L9 


L8 and (comparS adj3 addressS) 


2 


T rv 

L9 


T O 

L8 


L7 and ((replacS or updatS) with addressS) 


15 


T O 

L8 


L/ 


T A A- T C 

L4 or Lj 




L/ 


L6 


L3 and PNNIATM 


0 


L6 


T r 
Lj 


Li ana rINJNl 


/4 




T j4 

L4 


L3 and (PTSE or PTSP) 


11 


L4 


L3 


709/$.ccls. 


17245 


L3 


L2 


LI and ((replace$ or updat$) with (addressS adj2 comparS)) 


27 


L2 


LI 


routing.ab. 


7186 


Li 



END OF SEARCH HISTORY 



h eb bgeee e bch f ff e ch 



Preeform Search 



Page 1 of 2 



Freeform Search 



Database: 



Term: 



US Pre-Grant Publication Full-Text Database 



US Patents Full-Text Database 



US OCR Full-Text Database 
EPO Abstracts Database 
JPO Abstracts Database 
Derwent World Patents Index 
IBM Technical Disclosure Bulletins 




Display: |10 I Documents in Display Format : jKWIC | Starting with Number |T 
Generate: O Hit List ® Hit Count O Side by Side O Image 



isigga 



aintempti 



Search History 



DATE: Wednesday, February 16, 2005 Printable Copy Create Case 



Set Name Query Hit Count Set Name 

side by side result set 

DB=USPT; PLUR=YES; OP=ADJ 



L26 


L17 and prefixS 


1 


L26 


L25 


L19 and (prefixS with (compar$ or updat$ or replacS or chang$)) 


1 


L25 


L24 


L19andprefix$ 


1 . 


L24 


L23 


L19 comparS 


0 


L23 


L22 


LI 9 and (PISE with (updat$ or chang$ or replacS)) 


1 


L22 


L21 


L20 and (PTSE with (updat$ or chang$ or replac$)) 


1 


L21 


L20 


L19 and PISE 


1 


L20 


L19 


6208623. pn. 


1 


L19 


L18 


LI 7 and PTSE 


2 


L18 


L17 


(6606303 or 6243384 or 6208623 or 6002674).pn. • 


4 


L17 


L16 


L7 and ((replac$ or chang$ or updatS) adj3 prefix) 


0 


L16 


L15 


L7 and prefix 


16 


L15 


L14 


L7 and (chang$ adj3 address$) 


6 


L14 


L13 


L7 and (changS with address$) 


14 


L13 


L12 


L7 and ((replac$ or changS or updat$) with address$) 


20 


L12 


Lll 


L7 and SIG 


5 


Lll 



h eb bgeee e boh f ff e ch 



Freeform Search 



Page 2 of 2 



T 1 /\ 

LIO 


L7 and SIG 


5 


T 1 /\ 

LIO 


T C\ 

L9 


L8 and (comparS adj3 addressS) 


2 


L9 


T O 

La 


L7 and ((replacS) or updat3>) with addressS) 


15 


T O 

La 


T 1 

L 1 


T A T ^ 

L4 or Lj 


/4 


T T 
L/ 


T C 

Lo 


Li and FNNIAIM 


0 


T ^ 

Lo 


T C 

Lj 


T 1 ar\A DXTXTT 

Lj ana riNlNl 


lA 


T C 

Lj 


T A 

L4 


L3 and (PTSE or PTSP) 


1 1 


T A 

L4 


L3 


709/$.ccls. 


17245 


L3 


L2 


LI and ((replace$ or iipdatS) with (addressS adj2 comparS)) 


27 


L2 


LI 


routing.ab. 


7186 


Li 



END OF SEARCH HISTORY 



h eb bgeee e bch f ff e ch 



'AVEST Refine Search 



Page 1 of 2 



Refine Search 



Search Results - 



Term 


Documents 


REPLACS 


0 


REPLAC 


19 


REPLACA 


1 


REPLACABILITY 


79 


REPLACABLE 


1257 


REPLACABLEY 


1 


REPLACABLE-FLAG 


1 


REPLACABLY 


188 


REPLACAED 


4 


REPLACARDING 


2 


REPLACATED 


2 


(L7 AND ((REPLACS OR UPDAT$) WITH ADDRESSS) ).USPT. 


15 




There are more results than shown above. Click here to view the entire set. 



Database: 



I US Pre-Grant Publication Full-Text Database 



US Patents Full-Text Database 



US OCR Full-Text Database 
EPO Abstracts Database 
JPO Abstracts Database 
Derwent World Patents Index 
IBM Technical Disclosure Bulletins 



Search: 




iitnte:nt!Mp.ti 



Search History 



DATE: Wednesday, February 16, 2005 Printable Copy Create Case 




'WEST Refine Search 



Page 2 of 2 



T T 

L7 


L4 or L J 


74 


T n 

LlL 


L6 


L3 and PNNIATM 


0 


L6 


T C 


LJ ana rlNiNl 


/4 


T C 

Lj 


L4 


L3 and (PTSE or PTSP) 


11 


T A 

L4 


L3 


709/$.ccls. 


17245 


LI 


L2 


LI and ((replace$ or updat$) with (addressS adj2 comparS)) 


27 


L2 


Li 


routing.ab. 


7186 


LI 



END OF SEARCH HISTORY 



h eb bcgb eech 



Record List Display 



Page 1 of 27 



Hit List 



Bae:tiije:riatei(gsr(gSi 



Search Results - Record(s) 1 through 10 of 15 returned. 



□ 1. Document ID: US 6820134 Bl 

L8: Entry 1 of 15 



File: USPT 



Nov 16, 2004 



DOCUMENT-IDENTIFIER: US 6820134 Bl 

TITLE: Optimizing flooding of information in link-state routing protocol 
Detailed Description Text (54): 

(b) Examine every interface on the P2mpIntList 526 and perform the following: 
Compare the LSA being flooded with the one identified by the LSASent field 720 of 
the interface data structure 700. If the LSAs are the same, the LSA has already 
been sent on this interface and the next interface in the P2mpIntList 526 must be 
considered. Send the LSA in a link state update packet setting the destination 
address according to the rules in Section 13 of the RFC 2328. Set the LSASent field 
720 of the interface data structure 700 to the LSA that has just been sent. 

Detailed Description Text (58) : 

(b) Examine every interface on the P2pIntList 524 and perform the following: If the 
interface FloodingActive field 710 is clear, skip this interface and consider the 
next interface in the list. Send the LSA in a link state update packet setting the 
destination address according to the rules in Section 13 of RFC 2328. 

Current US Original Classification (1) : 
709/238 

Current US Cross Reference Classification ( 1 ) : 
709/242 



Other Reference Publication ( 4 ) : 
The ATM Forum Technical Committee. 
Version 1.0 ( PNNI 1.0). Mar. 1996. 



Private Network — Network Interface Specification 



Class if ication 



n 2. Document ID: US 6724724 Bl 

L8: Entry 2 of 15 



File: USPT 



Apr 20, 2004 



DOCUMENT-IDENTIFIER: US 6724724 Bl 

** See image for Certificate of Correction ** 

TITLE: System and method for resolving an electronic address 
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Brief Summary Text (9) : 

Each router 18, 22 typically maintains a table of address translations, such as the 
translation of device 22 's X.25 address to device 22 's TCP/IP address. These 
addresses are typically hard coded into the routers 18-20. Accordingly, if an 
address for a device changes, then each router 18-20 that includes that device's 
address will typically need to be accessed and the address will have to be changed. 
Since it is fairly common for a network to have its address scheme changed, it may 
be sub sjLajitj.a.l.l-V— t.ime ^ cons um xn g to— exifiure that each router that contained each o f 
t he changed addressee is accessed and updated . Additionally, the process of 
individually changing an address in all the routers that maintain that address may 
be error prone. 



-BetaTled Description Text (20) : 
If no translation is required, then device B is directly contacted (step 206) . If, 
however, the route to device B does require translation, then a name resolution 
service, such as a domain name server (DNS) is contacted (step 208) . The DNS which 
is contacted by the router may be a DNS local to the router, or a specific DNS 
identified in the router's routing table that contains the information to 
facilitate the address translation. Accordingly, only a relatively small number of 
DNSs would require updates of changes of addresses in order to dynamically affect 
all routers requesting that address . 



Detailed Description Text (21) : 

Router C passes the protocol^ specific address, such as the X.25 address, to the DNS 
(step 210) . The DNS then looks up its database for an address translation of the 
protocol specific address (step 212) . For example, the DNS may look up its database 
for an address translation of an X.25 address to an associated TCP/IP address. 
Normally, a DNS is typically used to resolve a host name to a TCP/IP address. For 
example, a host name such as www.cisco.com may be resolved by a DNS to a TCP/IP 
address such as 192.21.23.45. This resolution is typically performed by looking up 
a table in the DNS that associates the host name to a TCP/IP address. In this 
embodiment of the invention, the DNS is used to translate one protocol specific 
address to another protocol specific address by replacing the host name information 
with a protocol specific address . Accordingly, a protocol specific address, such as 
an X.25 address, may be translated to a TCP/IP address. Additionally, the IP 
address portion of the table may also be substituted by another protocol specific 
address, such as an ATM address. 

Current US Cross Reference Classification (3) : 
709/230 

Other Reference Publication (3) : 

Dillon, Kevin, " PNNI : Effortless Expansion for ATM Networks", Dialog (R) File 647, 
ATM Forum Bay Networks, Nov. 7, 1998. 

CLAIMS : 

3. The method of claim 2, further comprising: updating the table in the name 
resolution service element such that one or more addresses stored in the table may 
be resolved into a selected one of the first and second protocols. 

11. The medium of claim 10, further operable to: update the table in the name 
resolution service element such that one or more addresses stored in the table may 
be resolved into a selected one of the first and second protocols. 

16. The computer devi ce of claim 15, wherein the table in the name resolution 
service element is updated such that one or more addresses stored in the table may 
I be resolved into a selected one of the first and second protocols. 

|22. The apparatus claim 20, wherein the table in the name resolution service 
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element is updated such that one or more addresses stored in the table may be 
resolved into a selected one of the first and second protocols. 



Attachments 



□ 3. Document ID: US 6643289 Bl 

L8: Entry 3 of 15 



File: USPT 



Nov 4, 2003 



DOCUMENT-IDENTIFIER: US 6643289 Bl 

TITLE: Method of MPOA status change notification 



Detailed Description Text (41) : 

An MPS or MPC that receives the targetless LE_ARP message with or without a 
standard MPOA identification TLV, functions normally as defined in the ATM Forum 
MPOA standard as described above with "respect to the LEG ATM address, the MAC 
address and the MPOA identification TLV association (step 92). A LEC receiving such 
a frame, operates the same as defined in the standard, whereby the MAC to ATM 
binding entry is updated to reflect the MPOA identification TLV, Note that in cases 
where more than one entry corresponds to an ATM address, all entries are updated . 

Current US Cross Reference Classification (1) : 
709/223 

Other Reference Publication (2) : 

Przygienda Proxy PNNI augmented routing. ATM, 1998, ICATM-98, '1998 1st IEEE 
International Conference, pp. 371-377.* 



Clajsifioation 



□ 4. Document ID: us 6639901 Bl 

L8: Entry 4 of 15 



File: USPT 



Oct 28, 2003 



DOCUMENT-IDENTIFIER: US 6639901 Bl 

TITLE: Apparatus for and method for supporting 802. IQ VLAN tagging with independent 
VLAN learning in LAN emulation networks 



Brief Summary Text (9) : 

The current standard solution for routing in a private ATM network is described in 
Private Network Node Interface (PNNI) Phase 0 and Phase 1 specifications published 
by the ATM Forum. The previous Phase 0 draft specification is referred to as 
Interim Inter-Switch Signaling Protocol (USP) . The goal of the PNNI specifications 
is to provide customers of ATM network equipment some level of multi-vendor 
interoperability . 

Brief Summary Text (67): 
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The learning process observes the source MAC addresses of frames received on each 
port and updates the filtering database accordingly. The VID of the frame is used 
to ensure that the address information is learnt relative to the VLAN of the frame. 
The learning process is able to determine the port through which particular end 
stations in the bridged LAN can be reached by inspection of the source MAC address 
field and VID of received frames: It records this information in the filtering 
database . 

Detailed Description Paragraph Table (1) : 

DETAILED DESCRIPTION OF THE INVENTION Notation Used Throughout The following 
notation is used throughout this document. Term Definition AAL ATM Adaptation Layer 
ANSI American National Standards Institute ARP Address resolution Protocol ATM 
Asynchronous Transfer Mode BUS Broadcast and Unknown Server CCITT Comite Consulatif 
International Telegraphique et Telephonique DA Destination Address DDVC Data Direct 
Virtual Connection ELAN Emulated Local Area Network FCS Frame Check Sequence FDB 
Filtering Database FDDI Fiber Distributed Data Interface FID Filtering identifier 
IISP Interim Inter-Switch Signaling Protocol IP internet Protocol IPX Internetwork 
Packet Exchange ITU International Telecommunications Union IVL Independent VLAN 
Learning LAN Local Area Network LANE LAN Emulation LE LAN Emulation LEG LAN 
Emulation Client LEGS LAN Emulation Configuration Server LES LAN Emulation Server 
LNNI LAN Emulation Network to Network Interface LUNI LAN Emulation User to Network 
Interface MAC Media Access Control MMAC Multicast Media Access Control GUI 
Organizational Unit Identifier P2M Point-to-Multipoint P2P Point-to-Point PDU 
Protocol Data Unit PNNI Private Network to Network Interface PVC Permanent Virtual 
Circuit PVID Port VLAN Identifier SA Source Address SAR Segmentation and Reassembly 
SCSP Server Cache Synchronization Protocol SMS Selective Multicast Server SVC 
Switched Virtual Circuit SVL Shared VLAN Learning TCI Tag Control Information TLV 
Type, Length, Value TPID Tag Protocol Identifier UNI User to Network Interface VCC 
Virtual Channel Connection VCI Virtual Circuit Identifier VID VLAN Identifier VLAN 
Virtual Local Area Network VPI Virtual Path Identifier Definitions Used Throughout 
The following definitions are used throughout this document. Term Definition Frame 
A unit of data transmission on an IEEE 802 LAN MAC that conveys a Protocol Data 
Unit (PDU) between MAC Service users. There are three types of frame: Untagged, 
VLAN-Tagged and Priority-Tagged. IVL Configuration and operation of the Learning 
Process and the Filtering Database such that, for a given set of VLANs, if a given 
individual MAC address is learnt in one VLAN, that learnt information is not used 
in forwarding decisions taken for that address relative to any other VLAN in the 
given set. SVL Configuration and operation of the Learning Process and the 
Filtering Database such that, for a given set of VLANs, if an individual MAC 
address is learnt in one VLAN, that learnt information is used in forwarding 
decisions taken for that address relative to all other VLANs in the given set. Tag 
A Tag Header allows user priority information, and Header optionally, VLAN 
identification information, to be associated with a frame. Tagged A frame that 
contains a Tag Header immediately following Frame the Source MAC address field of 
the frame. Untagged A frame that does not contain a Tag Header immediately Frame 
following the Source MAC address field of the frame. VLAN A subset of the active 
topology of a Bridged Local Area Network. Associated with each VLAN is a VLAN 
Identifier (VID) . VLAN- A property of Bridges or end stations that recognize aware 
and support VLAN-Tagged Frames. VLAN- A property of Bridges or end stations that do 
not recognize unaware VLAN-Tagged Frames. 

Current US Cross Reference Classification (4 ) : 
709/238 
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□ 5. Document ID: US 6606303 Bl 

L8: Entry 5 of 15 File: USPT Aug 12, 2003 



DOCUMENT-IDENTIFIER: US 6606303 Bl 

TITLE: Method and device in a packet switched network 

Brief Summary Text ( 6 ) : ^ — j 
In a private Asynchronous Transfer Mocfe (ATMl/ network the 



In a private Asynchronous Transfer Moqe (ATM)/ network the PNNI f unction, as 
specified by the ATM Forum will probably~become the chosen tunction for resource 
management with respect to routing and signalling, and other functions. A part of 
the PNNI is a so called dynamic routing protocol meaning that a node in the network 
will announce and update information regarding its own identity, the resources on 
its outgoing links and in the node, and address reachability, to all neighboring 
nodes. This way, in the end all nodes in the network will have a complete 
hierarchical view of the topology of the network, including its available 
resources . 

Brief Summary Text (7) : 
\J The PNNI protocol is defined for use between private ATM switches and between 

private ATM networks. The abbreviation PNNI stands for either Private Network Node 
Interface or Private Network-to-Network Interface, reflecting these two areas of 
use. PNNI routing is used in a private network of ATM switching systems. PNNI 
includes a routing protocol for distribution of topology information between 
switches and groups of switches. The functions of the PNNI routing protocol 
include, among other things: discovery of neighbours and link and node status, 
siiachr.gni^zation of topology databases, construction of the ro.u tajig_hijexax chy^ 
transmissi'on.^of PNNI topoloq:^;— s^alrg-elements from each node to all other nodes. 



Brief Summary Text (11) : 

To avoid the problems of hop-by-hop routing PNNI uses source routing for all 
connection setup reguests . The first node in a peer group selects the entire path 
across that peer group and across all other peer groups for the purpose of reaching 
the destination. The path is encoded as a set of Designated Transit Lists (DTLs) 
explicitly included in the connection setup request. The DTLs specify every node 
used in transit across the peer group and may also specify the logical links to be 
used between the nodes. If a node along the path is unable to follow the DTL for a 
specific connection setup request the node must perform a so called crankback, that 
is, return the connection setup request to the node in which the DTL was created. 

Brief Summary Text (18) : 

Routing for connections with multiple performance constraints complicates the 
problem in two ways. First, each link must be described in terms of multiple 
parameters. Second, the ability of a link to participate in a path depends on the 
requirements of the connection being routed. Having fill topology information and 
status about actual network resources and capacity is necessary to be able to 
compare different link costs with each other in order to build least-cost routes to 
every other destination in the network. The PNNI distributes complete routing 
information to all nodes, making it desirable to use Dijkstra's algorithm, which, 
however can only optimize on one parameter. For example, the path for which the 
delay is minimized may very well have an unacceptably low bandwidth or high delay 
variation, or vice versa. 

Brief Summary Text (30) : 

The parameters used comprise the maximum cell transfer delay (CTD) , the peak-to- 
peak Cell Delay Variation (CDV) , the Available Cell Rate (AvCR) , the Maximum Cell 
Rate (MCR) and the Cell Loss Ratio (CLR) . An Administrative Weight (AW) may also be 
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included. These parameters are specified in the PNNI routing specification, agreed 
by the ATM Forum, and will be explained in somewhat more detail below. 

Brief Summary Text (36) : 

The routing with respect to multiple constraints in a PNNI network environment 
specifically addressing the traffic contracts of the rt-VBR service categories is 
enabled. 

Drawing Description Text (2) : 

FIG. 1 shows schematically a packet switch network with two hierarchical levels 
according to the PNNI protocol. 

Detailed Description Text (2) : 

FIG. 1 is a schematic representation of a packet switch network comprising a number 
of logical nodes and with two hierarchical levels. The lowest level of the PNNI 
hierarchy comprises the logical nodes that are organized into peer groups. The 
nodes in a peer group exchange information with the other nodes in the group, so 
that all nodes in the group have an identical view of the group and of other peer 
groups. Each logical node sees all nodes in its own peer group, but sees every 
other peer group only as a single node. 

Detailed Description Text (11): 

In PNNI, links are advertised unidirectionally, in the outgoing direction, but 
connections are always bidirectional, both directions using the same route. 
Therefore, the associated total link cost of a bidirectional link takes the network 
resources allocated both directions into consideration when computing the link 
cost. 

Detailed Description Text (39) : 

A routing table is updated when the available resources of a node or link is 
changed or when the address reachability in the network is changed. 

Current US Cross Reference Classification (2) : 
709/241 j 
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□ 6. Document ID: US 6523696 Bl 

L8: Entry 6 of 15 



File: USPT 



Feb 25, 2003 



DOCUMENT-IDENTIFIER: US 6523696 Bl 

TITLE: Communication control device for realizing uniform service providing 
environment 



Detailed Description Text (54): 

Note that, in this embodiment, it is assumed that the AV control terminals 2 and 5 
carry out communications with each other by using the IP, but it is also possible 
to realize this feature by using the other network layer technology (such as 
Netware, CLNP (Connection-Less Network Protocol), etc.) or the other technology 
(such as I -PNNI (Integrated P-NNI, 1394 protocol, etc.) instead of the IP. 

Detailed Description Text (55) : 

Also, in this embodiment, the set up of the connection (channel) between the AV 
control terminals 2 and 5 is made by using the protocol called FANP, but it is 
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easily possible to realize this feature by using the other connection set up 
protocol such as RSVP (Resource Reservation Setup Protocol), ST2 (Stream Transport 
Protocol-2), or I -PNNI, instead of the FANP. 

Detailed Description Text (280) : 

Namely, the AV connection device 2201 checks that it is the destination of the 
received IP packet by referring to the destination address of the received IP 
packet (step S5201), and then carries out the packet filtering processing by 
referring to the packet filter table 2209 (step S5202) . When the source address of 
this packet is registered in the packet filter table 2209, whether a set of the 
destination IP address and the destination port number of this packet is registered 
in the address and port number conversion table 2207 or not is checked (step 
S5203) . If it is registered, these destination IP address and destination port 
number are replaced by the corresponding IP address (private IP address ) and first 
port number of the home network side (step S5204), and this IP packet is 
transmitted to the home network 2010 (step S5205) . In this manner, the address 
conversion from the global IP address and the second port number to the private 
address and the first port number is carried out. 

Detailed Description Text (284): 

Namely, the AV connection device 2201 checks whether a set of the source IP address 
and the source port number of the received IP packet is registered in the address 
and port number conversion table 2207 or not (step S5301 and S5302) . If it is 
registered, these source IP address and source port number are replaced by the 
corresponding IP address (global unique IP address ) and second port number of 
Internet side (step S5303) , and this IP packet is transmitted to Internet 2101 side 
(step S5304) . 

Current US Original Classification (1) : 
709/223 

Current US Cross Reference Classification (1) : 
709/236 
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n 7. Document ID: US 6243384 Bl 

LB: Entry 7 of 15 ' File: USPT Jun 5, 2001 



DOCUMENT-IDENTIFIER: US 6243384 Bl 

TITLE: Address analysis for asynchronous transfer mode node with PNNI protocol 
Abstract Text (1) : 

An ATM switching node (20) which implements PNNI protocol has a Jab le (known as the 
consolidated table) which stores plural records, each record associating a 
connection request input field with corresponding routing information. 'JUlS— Qode_Jia5^ 
tabjj' mRjrftfeenan ce logic (78) which updates the table to consolidate therein both 
records initiated by operator input and records developed from PNNI updating 
information. The PNNI u pdating in f ormat iaD— ls_ aenerated bv a PNNI protocol _ unit . 
(56) which consults a topology database of the node. Provision of the consolidate 
table obviates consultation of multiple tables. 

Brief Summary Text (8) : 

A particular protocol, known as " PNNI ", has been developed for use between private 
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ATM switches, and between groups of private ATM switches. Consistent with these two 
potential employments, " PNNI " stands for either Private Network Node Interface, or 
Private Network-to-Network Interface. Thus, PNNI is a routing information protocol 
that enables multi-vendor ATM switches to be integrated in the same network. The 
PNNI protocol is defined e.g., by The ATM Forum's Private Network. sub. — Network 
Interface Specification Version 1.0 ( PNNI 1.0), af -pnni -0055 . OOP (March 1996). 

Brief Summary Text (9) : 

Each private ATM switch can be referred to as a (lowest level) node, each node 
having particular identifiers. Two nodes are connected together by a physical link, 
and many such nodes may be connected together. In PNNI parlance, nodes can be 
grouped together to form "peer groups". Each node exchanges certain identifying 
packets (e.g., "Hello" packets) with its immediate neighbors, so that each node can 
determine certain state information. The state information includes the identity 
and peer group membership of the node's immediate neighbors, and the status of the 
node's links to its neighbors. Each node uses the state information to prepare 
"PNNI Topology State Elements" ( PTSEs ) [henceforth also referred to as "topology 
messages"] . Nodes belonging to the same peer group exchange information with one 
another in a process known as "flooding", so that all nodes of the peer group have 
an identical view of the peer group. 

Brief Summary Text (10) : 

Using the topology messages that it receives, each node builds its own topology 
database. The topology database essentially constitutes the node's view of the 
universe, e.g., the other nodes in its peer group, connections to other peer 
groups, and connections to private and public networks. Topology messages are sent 
in reoccurring fashion from each node, so that on the basis of PNNI information the 
topology database of each node is frequently updated by the relatively automatic 
flooding of topology messages. U.S. Pat. No. 4,920,529 to Sasaki et al . discloses 
e.g., a mode of reconfiguring databases wherein network reconfiguration information 
is switched from a preparatory side to an operating side for usage. 

Brief Summary Text (12): 

The topology database of a node is important in view of the fact that PNNI uses 
source routing for all connection setup requests. In this regard, when a user 
requests a connection setup, an originating node (i.e., the first switching node 
encountered) chooses a general path to the destination, the general path being 
specified in accordance with the detail of the hierarchy known to the originating 
node. The path can be chosen using a path selection algorithm, which may vary from 
node to node. The path selection algorithm uses the information stored in the 
topology database in order to choose the general path to the destination, as well 
as other factors such as the connection's service category, traffic 
characteristics, and quality of services requirements, for example. The path is 
encoded as a Designated Transit List (DTL) , which is included in the connection 
setup request. The path specifies every node to be used in transit across the peer 
group to which the originating node belongs, and refers to higher level nodes which 
are to be used in reaching the destination. When the connection setup request 
reaches another node level, e.g., another peer group, the ingress node of the newly 
reached peer group selects the particular path across the newly reached peer group, 
consistent with the general path chosen by the originating node (unless a problem 
occurs) . 

Brief Summary Text (15) : 

ATM switching node which implements PNNI protocol has a table (known as the 
consolidated table) which stores plural records, each record associating a 
connection request input field with corresponding routing information. The node has 
table maintenance logic which updates the table to consolidate therein both records 
initiated by operator input and records developed from PNNI updating information. 
The PNNI updating information is generated by a PNNI protocol unit which consults a 
topology database of the node. Provision of the consolidate table obviates 
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consultation of multiple tables. 
Brief Summary Text (18): 

The node also includes a static table in which operator input information is stored 
for use in developing the records initiated by operator input. The operator input 
information stored in the static table and the PNNI updating information are merged 
in the inactive version of the consolidated table during table updating. 

Drawing Description Text (14): 

FIG. 8 is a diagrammatic view depicting messages involved the PNNI protocol 
updating of a consolidated table. 

Drawing Description Text (15,) : 

FIG. 8A is a flowchart showing actions taken by table maintenance logic in 
connection with the PNNI protocol updating of a consolidated table. 

Detailed Description Text (3) : 

FIG. 1 shows an ATM switching node 20 according to an embodiment of the invention 
and which employs PNNI protocol. ATM switching node 20 includes a switch fabric or 
switch core 22 having core ports 24. sub. 0 -24. sub. n which receive ATM cells, and 
core ports 26. sub. 0 -26. sub. n from which ATM cells leave switch core 22. In the 
illustrated embodiment, ports 24. sub. 1 -24. sub. n are connected by physical links 
34. sub. 1 -34. sub. n to other ATM nodes; ports 26. sub. 1 -26. sub. n are connected by 
physical links 36. sub. 1 -36. sub. n to other ATM nodes. Although not shown, it should 
be understood that one or more circuit boards may be connected between a core port 
and a physical link for various purposes, for example the handling ingress or 
egress ATM cells as the case may be, particularly for buffering and conversion 
between external and switch-internal VPI/VCI assignments. 

Detailed Description Text ( 4 ) : 

In addition to switch core 22, ATM switching node 20 includes a node control system 
40 which supervises operation of ATM switching node 20 and which performs PNNI- 
related operations including source routing. In the particular embodiment shown in 
FIG. 1, node control system 40 is situated on a circuit board which is connected to 
send ATM cells via physical link 34. sub. 0 to switch core 22 (i.e., to core port 
24. sub. 0) and to obtain ATM cells from switch core 22 (i.e., core port 26. sub. 0) 
via physical link 36. sub. 0. Although shown as occupying only one board in the 
illustrated embodiment, it should be understood that in other embodiments the 
functions of node control system 40 can be distributed as desired among plural 
circuit boards and therefore addressable through plural ports of switch core 22. 

Detailed Description Text (10) : 

In contrast to the static data maintained in static table 90, address and routing 
data can also be dynamically provided to table handling unit 60 in view of the PNNI 
protocol implemented by ATM switching node 20. In this regard, topology cell 
handling unit 52 recurrently receives topology messages (e.g., PTSEs ) in the form 
of ATM cells from other nodes in the same peer group with ATM switching node 20. 
The topology cell handling unit 52 builds the topology database of ATM switching 
node 20. The routing determination unit 56, which functions as the PNNI protocol 
unit (PNNIR) implements the node's path selection algorithm based on the 
information stored in the topology database. Routes or paths determined by the path 
selection algorithm of routing determination unit 56 are forwarded to table 
maintenance logic 78 of table handling processor 70 for use in an appropriate 
results field of routing analysis section 84 of the consolidated table 80. 

Detailed Description Text (17) : 

FIG. 4A together with FIG. 4B show a second traffic case in which node 20 is 
involved in connection setup for a connection from the user having address 7192345 
(connected by UNI 11 to node 20) to a user in private network 120 having address 
5575956. FIG. 4B shows a connection request message 4B-1 from user having address 
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7192345 to node 20, the connection request message 4B-1 including the called party 
number {e.g., address 5575956) of the called party. Upon receipt of the connection 
request message 4B-1, call control unit 54 sends the address 5575956 to address 
analysis logic 72 of table handling processor 70. The address analysis logic 72 
locates in address analysis section 82 of the active consolidated table a record 
which has the address 55 as an input value. As shown in the example table of FIG. 
2, the second record of address analysis section 82 has such value, along with a 
paired result value of "RC7I". The result value "RC-1" indicative of a routing case 
is returned by address analysis logic 72 to call control unit 54 as indicated by 
message 4B-2. Upon receipt of the routing case result value "RC-1", call control 
unit 54 sends message 4B-3 (including the result value "RC-1") to routing logic 74. 
The routing logic 74 consults routing analysis section 84 of table 80 (see FIG. 2), 
and using RC-1 as an index returns a list of routes message 4B-4. The list of 
routes message 4B-4 includes the three routes or paths garnered from the second 
record of routing analysis section 84 of table 80, i.e., UNIRoute 1; PNNIA.1.3; and 
PNNIA.2. The first such route (UNIRoute 1) is over interface UNI 13 which connects 
node 20 to private network 120. The second route (PNNIA.1.3) is through node A. 1.3 
and a UNI connecting node A. 1.3 to private network 120. The third route (PNNIA.2) 
is through peer group A. 2 (via node A. 1.3) and over a UNI connecting peer group A. 2 
to private network 120. the order of the routes/paths in the list of routes 
messages is indicative of the priority or preference. The particular priority 
specified in the results field is a result of operator input, since the priority 
between PNNI and UNI/BICI is set by the operator. The ultimate choice regarding 
priority is up to call control unit 54. Regardless of such choice, the traffic case 
of FIG. 4A is thus seen as being from an originating UNI to an outgoing UNI. 

Detailed Description Text (21) : 

The table maintenance logic 78 of table handling unit 60 of the present invention 
provides for the consolidated active table 80, and allows for the table to be 
updated in two different ways. As diagrammatically depicted in FIG. 7, the table 
maintenance logic 78 of table handling unit 60 can receive updating input both from 
an operator (e.g., via workstation 98) and from the network via the PNNI protocol 
(e.g., in the form of a signal pnni info from routing determination unit 56 
[PNNIR]). As shown in FIG. 7, the operator's updating input is stored by table 
maintenance logic 78 in static table 90, while the PNNI updating input is stored by 
table maintenance logic 78 in inactive table SOB. Advantageously, table maintenance 
logic 78 merges the operator's updating input stored in static table 90 into 
inactive table SOB as indicated by arrow M. After the merging operation, the table 
containing the merging results (table SOB) is linked in to become the active table 
(table SOA), as represented by arrow L in FIG. 7. 

Detailed Description Text (22) : 

As depicted in FIG. 7, via table maintenance logic 78 the operator can update one 
or more sections of static table 90, i.e., address analysis section 92, routing 
analysis section 94, or local look-up section 96. The static table 90 is then 
merged by table maintenance logic 78 with an inactive one of the consolidated 
tables (i.e., a copy of the active consolidated table maintained on a non- 
operational side of table handling unit 60) . 

Detailed Description Text (23) : 

When table maintenance logic 78 updates the address analysis section 82 of the 
active table SOA, a copy of the active table SOA is made on the non-operational 
side, e.g., inactive table SOB. Since the routing determination unit 56 [PNNIR] 
typically routinely obtains PNNI information about existing nodes in the network, 
table maintenance logic 78 uses such PNNI information to update the address 
analysis section 82 of inactive table SOB. Alternatively or additionally, address 
analysis section 82 can be updated when updating input is received from an operator 
and first stored in address analysis section 92, followed by merger of the data 
from address analysis section 92 into the address analysis section 82 of the 
inactive table SOB. The operator preferably specifies the address in ATM end system 
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format, which is described in ATM User-Network Interface (UNI) Signalling 
Specification Version 4.0. By either updating mode (operator or PNNI ) , when a 
routing case is provided as a result, a verification is made by table maintenance 
logic 78 that the routing case is defined in routing analysis section 84 . 

Detailed Description Text (24): 

The routing analysis section 84 of the active table can also be updated. As in the 
case of updating the address analysis section 82, a copy is made of the active 
table to form the inactive table BOB. The routing analysis section 84 is updated by 
the operator, with the updating information first stored in routing analysis 
section 94 of static table 90 and then merged with routing analysis section 84 of 
the inactive table 80B. Then, after merger, the updated information is included in 
the active table BOA. An operator is not allowed to remove a routing case that is 
used in address analysis section 82. Moreover, when a routing case is defined by 
the operator, a check is made by BICI/UNI to ensure that the route is defined. 

Detailed Description Text (25) : 

FIG. 8 together with FIG. 8A show updating of the active table BOA accomplished by 
the PNNI protocol, e.g., PNNI updating. FIG. 8A shows basic steps performed by 
table maintenance logic 78 upon receipt of the PNNI updating information indicated 
by message 8-1 ( pnni info) in FIG. 8. In FIG. 8, "ANA" refers to table handling 
unit 60; and "PNNIR" refers to routing determination unit 56. PNNI updating begins 
when table maintenance logic 78 receives PNNI updating information from routing 
determination unit 56 [PNNIR], as indicated by message 8-1 ( pnni info) in FIG. B. 

Detailed Description Text (26) : 

In particular, step 8A-1 shows table maintenance logic 78 receiving the PNNI 
updating information from routing determination unit (PNNIR) 56. The PNNI data 
obtained at step 8A-1 is in the form of a list which is included in the pnni info 
signal, which signal contains all addresses that have been flooded out and the 
nodes to which they are connected. At step BA-2, an inactive table SOB (see FIG. 
11) is prepared on a non-operational side of table handling unit 60 by copying the 
current active table 80A. The active table BOA is on an operational side of table 
handling unit 60. As step 8A-3, all data in static table 90 is obtained by table 
maintenance logic 78 for and copied into the inactive table BOB. 

Detailed Description Text (27) : 

At step 8A-4 The list of data received from PNNI at step 8A-1 is divided into one 
element for each address, i.e., one entry for each address. For example, for 
address "55" the element {55, A. 1.3, A2} is prepared, the element having the values 
A. 1.3 and A2 for its results field (see FIG. 2). Other comparable elements 
similarly understood with respect to FIG. 2 include {727, A. 1.2, A2} and {400, A2}. 

Detailed Description Text (28) : 

Step 8A-5 begins a loop, with step 8A-5 being an attempt to store the PNNI 
addresses and corresponding results fields in the inactive table BOB. The attempt 
of step 8A-5 may be determined at step 8A-6 to be unsuccessful because, for 
example, an entry may already exist in inactive table BOB corresponding to the 
information sought to be stored. If an entry already exists in inactive table BOB, 
at step 8A-7 the stored static data is merged with PNNI data for that entry, with 
the merged result being used as replacement for the corresponding entry in the 
inactive table BOB. If an entry does not yet exist, then at step BA-8 a new entry 
is created in the inactive table BOB. Step 8A-5 is repeated for every address for 
which the PNNI has updating information, e.g., until all PNNI updates are processed 
as indicated by step 8A-9. 

Detailed Description Text (29) : 

After all PNNI updates have been processed, at step BA-IO the table maintenance 
logic 78 essentially switches tables by putting the inactive table BOB on the 
operational side and removing formerly active table BOA to the non-operational side 
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(see FIG. 11) . In other words, the table selector S in FIG. 1 is switched, and 
table SOB is linked to become the active table (see FIG. 7) . Upon completion of 
PNNI updating, a signal 8-2 is sent from table handling unit 60 to routing 
determination unit 56 to confirm completion of the PNNI updating. 

Detailed Description Text (30) : 

The foregoing discussion, with particular reference to FIG. 8 and FIG. 8A, 
describes the relative automatic PNNI updating. By contrast, FIG. 9 shows a 
procedure for an operator to update active table 80. In FIG. 9, "AnaMI" refers to 
an interface with the operator; "ANA" refers to table handling unit 60; and " PNNI " 
refers to the PNNI protocol implemented in routing determination unit 56 of ATM 
switching node 20. 

Detailed Description Text (33) : 

Assuming that PNNI updates as described in FIG. 8 and FIG. 8A are also possible, 
table maintenance logic 78 requests PNNI data from routing determination unit 56 
[PNNIR] by sending a poll -address message shown as message 9-8 in FIG. 9. In 
response to the poll-address message, routing determination unit 56 sends the pnni - 
info signal shown as message 9-9 in FIG. 9. The PNNI information is received by 
table maintenance logic 78. Then, the steps of FIG. 8A are performed by table 
maintenance logic 78, resulting in the merging of data from static table 90 with 
the PNNI data obtained from PNNIR. 

Detailed Description Text (37) : 

Advantageously, in the present invention only one table — the active table 80--need 
be searched when table handling unit 60 is forwarded a called party number or 
address by call control unit 54 in connection with connection setup. The table 80 
which is used as the active table is updated by both the operator (e.g., via 
workstation 98) and by the network (e.g., via the PSTEs of the PNNI protocol) . 

Current US Cross Reference Classification (3) : 
709/238 

Other Reference Publication (5) : 

The ATM Forum Technical Committee, Private Network-Network Interface Specification 
Version 1.0 (PNNI 1.0), af -pnni -0055 ■ OOP, Mar. 1996. 

Other Reference Publication (6) : 

The ATM Forum Slide Presentation, Complete Long-Term Solution : PNNI Phase 1, ATM 
PNNImod 1.0-9 A, 1996. 

CLAIMS,: 

1. An ATM switching node which implements PNNI protocol, the node comprising: 

a PNNI protocol unit which uses a topology database to prepare PNNI updating 
information; 

a table which stores plural records, each record associating a connection request 
input field with corresponding routing information, wherein the table has an active 
version and an inactive version copied therefrom, wherein the active version of the 
table is utilized in connection setup; 

table maintenance logic which updates the table to consolidate therein both records 
initiated by operator input and records developed from the network signaling 
updating information; wherein updating is performed on the inactive version of the 
table, and wherein when updating is completed the inactive version of the table 
becomes the active version of the table. 

4. The apparatus of claim 1, further comprising: 
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a static table in which operator input information is stored for use in developing 
the records initiated by operator input; and 

wherein the operator input information stored in the static table and the PNNI 
updating information are merged in the inactive version of the table. 

7. A method of operating an ATM switching node which implements PNNI protocol, the 
method comprising: 

receiving topology messages and building a topology database for the node; 

using the topology database to prepare PNNI updating information; 

consulting a table to obtain routing information associated with a corresponding 
connection request input field, the table having an active version and an inactive 
version copied therefrom; 

using the active version of the table in connection setup; 

updating the inactive version of the table by consolidating operator input 
information and the PNNI updating information; and 

when updating is completed, using the inactive version of the table as the active 
version of the table. 

9. The method of claim 7, further comprising: 

storing the operator input information in a static table; and 

merging the operator input information stored in the static table and the PNNI 
updating information in the inactive version of the table. 
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TITLE: Method of combining PNNI and E-IISP in an asynchronous transfer mode network 



Abstract Text (1) : 

A method of permitting older networks based on E-IISP routing to operate in newer 
PNNI based networks. The invention combines the PNNI and E-IISP routing schemes and 
permits their simultaneous execution in the same ATM network. The E-IISP routing 
scheme is modified so as to operate in unison with the minimal PNNI implementation 
configured on each node. The Hello protocol and associated Finite State Machine 
(FSM) are utilized to determine whether a remote node is in the same peer group. If 
it is determined that both nodes are in the same peer group, the ports on either 
side of the link are configured as standard PNNI type ports. If it is determined 
that the two nodes are from different peer groups, the ports on either of the link 
are configured as E-IISP type ports. Foreign address information is then exchanged 



h eb bgeeef e bch ef b e 



Record List Display 



Page 14 of 27 



between the two nodes thus permitting border nodes to learn about other peer groups 
from their respective remote nodes. Relatively large networks can be constructed 
that do not have any hierarchy as in networks running the full PNNI standard. Via 
the Hello protocol, changes made to links between nodes will be detected 
immediately and the port configuration modified appropriately. 

Brief Summary Text (9) : 

The current standard solution for routing in a private ATM network is described in 
Private Network Node Interface (PNNI) Phase 0 and Phase 1 specifications published 
by the ATM Forum. The previous Phase 0 draft specification is referred to as 
Interim Inter-Switch Signaling Protocol (IISP) . The goal of the PNNI specifications 
is to provide customers of ATM network equipment some level of multi-vendor 
interoperability. 

Brief Summary Text (10) : 

The Interim Local Management Interface (ILMI) for the PNNI protocol specification 
provides an auto-port configuration capability. This capability functions to 
minimize manual configuration operations for PNNI ports of switches. The Phase 0 
solution to auto-port configuration is based on hop by hop routing utilizing a 
'best match' scheme. The Phase 1 PNNI based solution is based on Open Shortest Path 
First (OSPF) with the additions necessary for ATM. This scheme is essentially a 
'source routing' scheme whereby each node has basic knowledge of the structure of 
the entire network and uses this knowledge to build a complete path from the source 
to the destination. When a connection is to be set up from a source to a 
destination, the source sends out a SETUP message that has within it the address of 
the destination. Each ATM network node along the way reads the next node from the 
SETUP message and forwards the message to an appropriate next node. This continues 
until the SETUP message arrives at its destination. 

Brief Summary Text (14) : 
PNNI Phase 1 

Brief Summary Text (15) : 

As part of the ongoing enhancement to the ATM standard by work within the ATM Forum 
and other groups, the Private Network to Network Interface ( PNNI ) protocol Phase 1 
has been developed for use between private ATM switches and between groups of 
private ATM switches. The PNNI specification includes two categories of protocols. 
The first protocol is defined for the distribution of topology information between 
switches and clusters of switches where the information is used to compute routing 
paths within the network. The main feature of the PNNI hierarchy mechanism is its 
ability to automatically configure itself within the networks in which the address 
structure reflects the topology. The PNNI topology and routing techniques are based 
on the well known link state routing technique. 

Brief Summary Text (17) : 

With reference to the PNNI Phase 1 specifications, the PNNI hierarchy begins at the 
lowest level where the lowest level nodes are organized into peer groups. A logical 
node in the context of the lowest hierarchy level is the lowest level node. A 
logical node is typically denoted as simply a node. A peer group is a collection of 
logical nodes wherein each node within the group exchanges information with the 
other members of the group such that all members maintain an identical view of the 
group. When a logical length becomes operational, the nodes attached to it initiate 
and exchange information via a well known Virtual Channel Connection (VCC) used as 
a PNNI Routing Control Channel (RCC) . 

Brief Summary Text (18) : 

Hello messages are sent periodically by each node on this link. In this fashion the 
Hello protocol makes the two neighboring nodes known to each other. Each node 
exchanges Hello packets with its immediate neighbors to determine its neighbor's 
local state informati on. The stste inf oirination includes the identity and peer group 
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membership of the node's immediate neighbors and the status of its links to its 
neighbors. Each node then bundles its state information in one or more PNNI 
Topology State Elements ( PTSEs ) which are subsequently flooded throughout the peer 
group. 

Brief Summary Text (19) : 

PTSEs are the smallest collection of PNNI routing information that is flooded as a 
unit among all logical nodes within a peer group. A node topology database consists 
of a collection of all PTSEs received, which represent that particular node's 
present view of the PNNI routing topology. In particular, the topology database 
provides all the information required to compute a route from the given source node 
to any destination address reachable in or through that routing domain. 

Brief Summary Text (20) : 

When neighboring nodes at either end of a logical length begin initializing through 
the exchange of Helios, they may conclude that they are in the same peer group. If 
it is concluded that they are in the same peer group, they proceed to synchronize 
their topology databases. Database synchronization includes the exchange of 
information between neighboring nodes resulting in the two nodes having identical 
topology databases. A topology database includes detailed topology information 
about the peer group in which the logical node resides in addition to more abstract 
topology information representing the remainder of the PNNI routing domain. 

Brief Summary Text (21) : 

During a topology database synchronization, the nodes in question first exchange 
PTSE header information, i.e., they advertise the presence of PTSEs in their 
respective topology databases . When a node receives PTSE header information that 
advertises a more recent PTSE version than the one that it has already or 
advertises a PTSE that it does not yet have, it requests the advertised PTSE and 
updates its topology database with the subsequently received PTSE. If the newly 
initialized node connects to a peer group then the ensuing database synchronization 
reduces to a one way topology database copy. A link is advertised by a PTSE 
transmission only after the database synchronization between the respective 
neighboring nodes has successfully completed. In this fashion, the link state 
parameters are distributed to all topology databases in the peer group. 

Brief Summary Text (22) : 

Flooding is the mechanism used for advertising links whereby PTSEs are reliably 
propagated node by node throughout a peer group. Flooding ensures that all nodes in 
a peer group maintain identical topology databases. A short description of the 
flooding procedure follows. PTSEs are encapsulated within PNNI Topology State 
Packets ( PTSPs ) for transmission. When a PTSP " is received its component PTSEs are 
examined. Each PTSE is acknowledged by encapsulating information from its PTSE 
header within the acknowledgment packet which is sent back to the sending neighbor. 
If the PTSE is new or of more recent origin then the node's current copy, the PTSE 
is installed in the topology database and flooded to all neighboring nodes except 
the one from which the PTSE was received. A PTSE sent to a neighbor is periodically 
retransmitted until acknowledged. 

Brief Summary Text (23) : 

Note that flooding is an ongoing activity wherein each node issues PTSPs with PTSEs 
that contain updated information. The PTSEs contain the topology databases and are 
subject to aging and get removed after a predefined duration if they are not 
refreshed by a new incoming PTSE . Only the node that originally originated a 
particular PTSE can re-originate that PTSE. PTSEs are reissued both periodically 
and on an event driven basis. 

Brief Summary Text (24) : 

As described previously, when a node first learns about the existence of a 
neighboring peer node which resides in the same peer group, it initiates the 
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database exchange process ir| order to synchronize its topology database with that 
of its neighbor's. The database exchange process involves exchanging a sequence of 
database summary packets which contain the identifying information of all PTSEs in 
a node topology database. The database summary packet performs an exchange 
utilizing a lock step mechanism whereby one side sends a database summary packet 
and the other side responds with its own database summary packet, thus 
acknowledging the received packet. 

Brief Summary Text (25) : 

When a node receives a database summary packet from its neighboring peer, it first 
examines its topology database for the presence of each PTSE described within the 
packet. If the particular PTSE is not found in its topology database or if the 
neighboring peer has a more recent version of the PTSE then the node requests the 
PTSE from the particular neighboring peer or optionally from another neighboring 
peer whose database summary indicates that it has the most recent version of the 
PTSE . 

Brief Summary Text (29) : 

After the peer processes the database summary packets, the missing or updated PTSEs 
can then be requested. In the Exchanging state the database summary packets contain 
summaries of the topology state information contained in the node's database. In 
the case of logical group nodes, those portions of the topology database that were 
originated or received at the level of the logical group node or at higher levels 
are included in the database summary. The PTSP and PTSE header information of each 
such PTSE is listed in one of the nodes database packets. PTSE ' s for which new 
instances are received after the exchanging state has been entered may not be 
included in any database summary packet since they will be handled by the normal 
flooding procedures. 

Brief Summary Text (30) : 

The incoming data base summary packet on the receive side is associated with a 
neighboring peer via the interface over which it was received. Each database 
summary packet has a database summary sequence number that is implicitly 
acknowledged. For each PTSE listed, the node looks up the PTSE in its database to 
see whether it also has an instance of that particular PTSE . If it does not or if 
the database copy is less recent, then the node either re-originates the newer 
instance of the PTSE or flushes the PTSE from the routing domain after installing 
it in the topology database with a remaining lifetime set accordingly. 

Brief Summary Text (31) : 

Alternatively, if the listed PTSE has expired, the PTSP and PTSE header contents in 
the PTSE summary are accepted as a newer or updated PTSE with empty contents. If 
the PTSE is not found in the node's topology database, the particular PTSE is put 
on the PTSE request list so it can be requested from a neighboring peer via one or 
more PTSE request packets . 

Brief Summary Text (32) : 

If the PTSE request list from a node is empty, the database synchronization is 
considered complete and the node moves to the Full state. 

Brief Summary Text (33) : 

However, if the PTSE request list is not empty then the Loading state is entered 
once the node's last database summary packet has been sent but the PTSE request 
list is not empty. At this point, the node now knows which PTSE needs to be 
requested. The PTSE request list contains a list of those PTSEs that need to be 
obtained in order to synchronize that particular node's topology database with the 
neighboring peer's topology database. To request these PTSEs, the node sends the 
PTSE request packet which contains one or more entries from the PTSE request list. 
The PTSE request list packets are only sent during the Exchanging state and the 
Loading state. The node can sent a PTSE request pack to a neighboring peer and 
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optionally to any other neighboring peers that are also in either the Exchanging 
state or the Loading state and whose database summary indicate that they have the 
missing PTSEs . 

Brief Summary Text (34): 

The received PTSE request packets specify a list of PTSEs that the neighboring peer 
wishes to receive. For each PTSE specified in the PTSE request packet, its instance 
is looked up in the node's topology database. The requested PTSEs are subsequently 
bundled into PTSPs and transmitted to the neighboring peer. Once the last PTSE and 
the PTSE request list has been received, the node moves from the Loading state to 
the Full state. Once the Full state has been reached, the node has received all 
PTSEs known to be available from its neighboring peer and links to the neighboring 
peer can now be advertised within PTSEs . 

Brief Summary Text (39) : 

Thus, the automatic exchange of network address prefixes causes the routing tables 
of each node to be updated and permits the signaling to ^come up^. This is in 
contrast to IISP Phase 0 which requires that link attributes to be set manually. 
This method is thus especially advantageous in large networks having more than two 
nodes. 

Brief Summary Text (41) : 

Note that the above described PNNI and IISP routing schemes are inherently 
different. In PNNI, only full address matching is permitted, i.e., an address must 
fully match the address entry in the topology database. In contrast, IISP permits 
partial address matching. The IISP routing method is a partially static routing 
scheme . 

Brief Summary Text (42) : 

In addition, there are many ATM switches currently in operation that support only 
the IISP type routing. It is desirable to permit the owners of many of these older 
ATM switches to upgrade their switches to the more modern PNNI type routing. 
Upgrades can be performed by upgrading the operating software within the switches. 
In order to permit upgraded nodes to operate in a PNNI network, the upgraded 
switches can only support a minimal PNNI configuration. This means that the 
hierarchical features of PNNI ■ are not supported. More specifically, in a minimal 
subset of PNNI, a node cannot function as a border node or as a Peer Group Leader 
(PGL) . A border node is a node that has a link to another peer group and executes a 
special finite state machine (FSM) . The PGL is the node that represents the whole 
peer group and functions as the key component for building large hierarchical 
networks . 

Brief Summary Text (43): 

A conflict exists, however, since a major benefit of PNNI is its ability to permit 
network designers to construct large hierarchical networks. Using PNNI , networks 
can be constructed that comprise peer groups having from dozens to over a hundred 
nodes. The concept is that many nodes in the same peer group can be represented as 
one node in a higher level of the hierarchy. Since PNNI utilizes a link state, 
source routing type routing scheme wherein each node has a view of the entire 
network, it is the hierarchy that permits the division of the network view into 
smaller chunks. In PNNI , very large portions of the network comprising a large 
number of nodes may be viewed by nodes in other peer groups as a single logical 
node . 

Brief Summary Text (44): 

A limitation of the older ATM switches currently in use is that they cannot support 
large PNNI networks. If the nodes in a network only support a minimal PNNI 
implementation, large hierarchical networks cannot be constructed. Thus, all the 
nodes in such a network will be at the same peer level. This causes each node in 
the peer group to include the whole peer in its network topology database. 
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including nodal, link and addressing information. 
Brief Sunrniary Text (47): 

The present invention provides a solution to permit older networks based on IISP 
routing to operate in newer PNNI based networks. The invention is a method which 
combines the PNNI routing scheme with an enhanced version of the IISP routing 
scheme which permits their simultaneous execution in the same ATM network. The IISP 
routing scheme is modified so as to operate in unison with the minimal PNNI 
implementation configured on each node. The modified IISP is termed enhanced IISP 
or E-IISP. 

Brief Summary Text (48): 

In the present invention, it is assumed that nodes are configured with a minimal 
PNNI implementation and they (1) cannot function as border nodes and (2) cannot 
function as peer group leaders. 

Brief Summary Text (49) : 

The method of the present invention utilizes the Hello protocol and associated 
Finite State Machine (FSM) to determine whether a remote node is in the same peer 
group. The peer group IDs are exchanged and examined. The addresses and levels are 
exchanged via the Hello protocol. If it is determined that both nodes are in the 
same peer group, the ports on either side of the link are configured as standard 
PNNI type ports. The Hello protocol, associated FSM and PTSE FSM continue in 
accordance with the standard. 

Brief Summary Text (51): 

Thus, the nodes within a peer group are connected by links of the PNNI type and 
border nodes between peer groups are connected by links of the E-IISP type. Since 
each node eventually learns about the address prefixes of other peer groups in the 
network using ILMI in combination with the method of the present invention, a 
source user connected to a source node can be routed to a destination user 
connected to a destination node anywhere in the network. 

Brief Summary Text (52): 

In this fashion, relatively large networks can be constructed that do not have any 
hierarchy as in networks running the full PNNI standard as opposed to the minimal 
PNNI implementation. To prevent switches from exceeding their limited memory 
capacity, it is recommended that the number of nodes placed in each peer group be 
limited. For example, the number of nodes in a peer group can be limited to 50 so 
as not to exceed the memory capacity of the switches. 

Brief Summary Text (53) : 

In addition, since the Hello protocol is always running, changes made to links 
between nodes will be detected immediately. In response to links being disconnected 
and reconnected to form different network configurations, a node may switch the 
port configuration type from PNNI to E-IISP and vice versa. When a port type is 
changed from E-IISP to PNNI, the locally registered addresses must be flushed from 
the topology database. 

Brief Summary Text (54): 

There is provided in accordance with the present invention, in an Asynchronous 
Transfer Mode (ATM) network having a plurality of nodes, the plurality of nodes 
configured to form one or more peer groups connected by one or more links, each 
node having a topology database and being capable of configuring each of its ports 
as either a Private Network Node Interface ( PNNI ) type port or an Enhanced Interim 
Inter-Switch Signaling Protocol (E-IISP) type port, a method of building ATM 
networks combining both PNNI and E-IISP schemes, the method comprising the steps of 
determining, on each node connected to a remote node via a link, whether the node 
and its remote node are from the same peer group, configuring the port associated 
with the link as a PNNI type port if the node and its remote node are from the same 
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peer group, configuring the port associated with the link as an E-IISP type port if 
the node and its remote node are not from the same peer group, transferring from 
the node to the remote node, all foreign addresses in the topology database of the 
node, registering the foreign addresses received by the remote node in the topology 
database of the remote node and flooding the foreign addresses from the remote node 
to other nodes that are members of the peer group of the remote node. 

Brief Summary Text (55) : 

The step of determining comprises the steps of executing a Hello protocol and 
associated Finite State Machine (FSM) of PNNI on each port configured as a non User 
to Network Interface (UNI) port and extracting a peer group ID from Hello messages 
received from a remote node located on the other side of the link each port is 
connected to. 

Brief Summary Text (56) : 

The method further comprises the step of executing a conventional Hello protocol 
and PNNI Topology State Element ( PTSE ) Finite State Machines (FSMs) of PNNI . The 
method further comprises the step of executing a conventional Hello protocol and 
PNNI Topology State Elements ( PTSE ) Finite State Machines (FSMs) of PNNI on each 
port regardless of whether the port is configured as a PNNI type port or an E-IISP 
type port. The method further comprises the step of changing the configuration of a 
port from a PNNI type port to an E-IISP type port in response to one or more 
changes to the configuration of the network. The method further comprises the step 
of changing the configuration of a port from an E-IISP type port to a PNNI type 
port in response to one or more changes to the configuration of the network. The 
method further comprises the step of transferring and registering the foreign 
addresses from the node to the remote node utilizing the Interim Local Management 
Interface (ILMI) protocol. 

Drawing Description Text (3) : 

FIG. 1 is a diagram illustrating an example ATM network having three peers wherein 
all nodes are running a minimal PNNI implementation; 

Detailed Description Text (5) : 

A diagram illustrating an example ATM network having three peers wherein all nodes 
are running a minimal PNNI implementation is shown in FIG. 1. The example network 
shown in FIG. 1 is presented for illustrative purposes only. ATM networks having an 
unlimited number of configurations are also within the scope of the present 
invention. In addition, to aid in the understanding principles of the present 
invention, the following description uses a PNNI level of 80 as an example. This in 
no way is meant to limit the scope of the present invention, as any PNNI level may 
be used with the invention. In addition, each link on each node is configured to be 
either a UNI port or a non-UNI port. Non-UNI ports may function either as a PNNI 
port or as an E-IISP port. It is thus assumed that each node in the network can 
configure its ports in accordance with the PNNI standard and in accordance with the 
E-IISP. Details of the PNNI protocol standard can be found in ATM Forum PNNI -1 
Specification, incorporated herein by reference. Details of E-IISP can be found in 
U.S. patent application Ser. No. 08/697,220, entitled A METHOD OF ROUTING IN AN 
ASYNCHRONOUS TRANSFER MODE NETWORK, now U.S. Pat. No. 5,940,396, and incorporated 
herein by reference in its entirely. More information on ATM networks can be found 
in the book ATM: The New Paradigm for Internet, Intranet and Residential Broadband 
Services and Applications, Timothy Kwok, Prentice Hall, 1998. 

Detailed Description Text (6) : 

It is important to note that the method of the present invention utilizes only the 
auto registration features of E-IISP. The routing features of PNNI are utilized 
rather than those of E-IISP. 

Detailed Description Text (7) : 

Referring to FIG. 1, the ATM network, generally referenced 10, comprises three peer 
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groups labeled Peer A 20, Peer B 30 and Peer C 40. Each peer group comprises a 
plurality of nodes 50 each connected by links. Each peer group also comprises one 
or more border nodes that connect one peer group to another. Peer A comprises a 
single border node 52 that is connected to neighboring nodes via PNNI links 42 and 
44. Peer B comprises three border nodes. Border node 54 is connected to border node 
52 in Peer A via E-IISP link 70. Node 54 is also connected to its neighboring node 
via PNNI link 80. Node 58 is also a border node connected to border node 62 in Peer 
C via E-IISP link 72. Likewise, border node 60 is connected to border node 64 in 
Peer C via E-IISP link 74. Node 64 is connected to its neighboring nodes via PNNI 
links 46, 48. 

Detailed Description Text (8) : 

Each peer group is assigned 'a peer group ID which consists of a 14 byte ID. The ID 
comprises 1 byte indicating fthe PNNI level in bits followed by 13 bytes indicating 
the address prefix up to the level number of bytes. In connection with addresses, 
the term significant length refers to number of valid bits of address prefix for a 
node configured originally. The significant length of an address prefix is less 
then or equal to 13 bytes (104 bits) . The term PNNI level refers to the number of 
bits which defines the level of the node in the PNNI hierarchy. The PNNI level is 
also less than or equal to 13 bytes. Typically the PNNI level is less than or equal' 
to the significant length. 

Detailed Description Text (9) : 

Address prefixes consist of 13 bytes. Note that all nodes in the same peer group 
have the same PNNI level and thus the address prefix of each node up to the PNNI 
level number of bits is the same. The bits following the PNNI level number of bits 
until the significant length are unique for each node. The bits following the 
significant number of bits are padded with zeros and not used. During the network 
setup stage, a 20 byte destination address is assigned. The 20 byte addresses is 
made up of a 13 byte address prefix following by the 6 byte MAC address followed by 
a 1 byte selector field. 

Detailed Description Text (10) : 

In the example presented herein to illustrate the method of the present invention, 
all the nodes in each peer have a PNNI level of 80, i.e., 10 bytes, in their PNNI 
configuration. Thus, the first 10 bytes of the prefix for each node in a peer group 
is common. The remaining 3 bytes are unique for each node within the peer group. 
All nodes in the network have the same 9 most significant bytes in their node 
address prefixes. In addition, each peer group has a peer group ID that is unique 
in the lO.sup.th byte of their prefix. All the nodes within the same peer have the 
same lO.sup.th byte in their node address prefix. Thus, the first 10 bytes of the 
address assigned to Peer A is 47 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . OA. The first 10 bytes 
assigned to Peer B is 47 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . OB. The first 10 bytes assigned to 
Peer C is 47 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . OC. The actual 14 byte peer group ID assigned 
to each peer group is shown in Table 1 below: 

Detailed Description Text (11) : 

Referring to FIG. 1, each node in the network supports ports that can be either 
PNNI ports or E-IISP ports. Each node that has a port configured as a non-UNI port, 
runs the Hello protocol and associated FSM of the PNNI standard at all times 
regardless of whether it is configured as a PNNI port of an E-IISP port. 

Detailed Description Text (12) : 

In operation, when a node receives the Hello message from a remote node, it 
examines the addresses to determine whether both node are in the same peer group or 
not. If the node determines that both nodes are in the same peer group then it 
configures that port as a PNNI type port. The regular Hello protocol, associated 
FSM and PTSE FSM are followed as if the link was a standard PNNI link. Note that in 
this example, two nodes will be in the same peer group if the two nodes are 
configured to have the same unique ID in the lO.sup.th byte of their address 
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prefix. In addition, since both nodes have the same PNNI level of 80, they are both 
at the same peer group level. Note that the peer group ID is extracted from the 
network prefix and level. Thus, the links between the nodes within each peer group 
are configured as PNNI links. 

Detailed Description Text (15): 

A logical flow diagram illustrating the combined routing scheme method of the 
present invention is shown in FIGS. 2A and 2B. The first step is that each node 
having a port configured as a non-UNI port runs the Hello protocol and associated 
FSM in accordance with the PNNI standard (step 170) . When a Hello message is 
received (step 172) the peer group ID is extracted from the network prefix and 
level (step 174). It is then determined whether the node and remote node are from 
the same peer group (step 176) . 

Detailed Description Text (16) : 

If both nodes are from the same peer group, they both configure their ports as PNNI 
type ports (step 178) . Processing continues with the Hello protocol and associated 
FSM in accordance with the PNNI standard (step 180). Also, PNNI standard PTSE FSM 
handling is also performed (step 182) . 

Detailed Description Text (17) : 

If it is determined that both nodes are, however, from different peer groups, the 
corresponding ports in both nodes are configured as E-IISP ports (step 184). Even 
though the port is configured as E-IISP, it retains PNNI functionality, e.g., the 
Hello protocol and FSM continues to run. One or more data elements are then 
exchanged between the ports (step 186) . Data is exchanged via ILMI protocol which 
is commonly used to exchange information between two nodes. One of the data 
elements exchanged includes the addresses of other known border nodes (step 188) . 
Each side sends the prefix plus the PNNI level (length) of its nodal address. Data 
can be exchanged via one of two ways (1) via peer group IDs in the Hello protocol 
messages or (2) via ILMI protocol method. 

Detailed Description Text (19) : 

Once a node learns the addresses from its remote node, it first registers the 
address in its topology database (step 190) . The node then floods the addresses 
throughout its peer (step 192) . The node packages the address, indicating that the 
address is a local reachable address, into a PTSE and floods this PTSE to nodes 
within its peer group. In one embodiment, the node floods two PTSEs : one PTSE 
contains the actual address as a standard PTSE, the second non-mandatory PTSE 
contains data indicating that that particular address is an E-IISP address. The 
address can be tagged as an E-IISP address by setting one or more flags in the 
PTSE. Nodes that are programmed to implement the method of the present invention 
will receive and process the foreign address information accordingly. Nodes that do 
not implement the method of the present invention, however, will receive the PTSE 
which is considered unknown, store it, flood it and age it but will otherwise 
ignore it . 

Detailed Description Text (20) : 

Using the method of the present invention, a network designer can build very large 
networks that do not have any hierarchy. Relatively small PNNI peer groups of, for 
example, 50 nodes or less, are connected together via E-IISP type links. 

Detailed Description Text (21) : 

A diagram illustrating an example ATM network having three peers and the address 
exchanges between the border nodes is shown in FIG. 3. The three peer groups A, B, 
C are connected together via links 70, 72, 74. Using the method of FIGS. 2A and 28, 
the links connecting nodes within the peer groups are configured as PNNI type 
links. The links connecting the border nodes 52 and 54; 58 and 62; 60 and 64 are 
configured as E-IISP type links. 
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Detailed Description Text (23) : 

In accordance with the present invention each node registers what it learns from, 
the remote node, i.e., its remote peer, on the other side of the E-IISP link. Once 
registered, they are flooded throughout the entire PNNI portion of the network 10 
thus permitting every destination to be reached. 

Detailed Description Text (26) : 

Although node 62 also is registered with address A*, node CI 64 is chosen since 
node 64 is less costly than node 62. The DTL used for PNNI routing would include 
the following nodes (C2, CI) . Node CI realizes it is the last node in the DTL, thus 
local routing must be utilized. In other words, the call is routed to either a UNI 
port, E-IISP port or IISP port. All three cases are non PNNI domain ports. Thus, 
node CI routes the call to node Peer B over link 74 without a DTL. 

Detailed Description Text (28): 

At border node A5 52 of Peer A, the call is handled as if a user directly connected 
to the node had requested the call. Thus, node A5 functions as if it was the 
originating (source) node. It thus performs a best match on the destination address 
(A*) which results in node Al 143 being chosen. A DTL is constructed comprising the 
nodes (A5, A4, A3, A2, Al) . The call is then routed using standard PNNI routing to 
node Al 143 to which the destination user is attached. 

Detailed Description Text (29) : 

It is an important aspect of the present invention that the ports on each node in 
the network that are configured as non-UNI ports, can change from PNNI type port to 
E-IISP port and vice versa. The main difference being that on a port configured as 
PNNI port, the standard PNNI protocol is active. While on the E-IISP ports, there 
is only an ILMI protocol that sends traps which include the foreign addresses 
learned by the node and stored in its PNNI topology database. The E-IISP port also 
functions to register any address that it receives from the remote node using the 
same mechanism. The node subsequently floods the foreign addresses to the other 
nodes in its peer group. 

Detailed Description Text (30) : 

It is also important to note that the PNNI Hello protocol and associated FSM 
mechanism that is used to determine which type of port the port should be 
configured to. The Hello protocol mechanism is used since it is assumed that the 
nodes in the network support only the minimal PNNI subset implementation which does 
not support border nodes. 

Detailed Description Text (31) : 

A -diagram illustrating an example' ATM network with a portion of the links 
disconnected is shown in FIG. 5. In this example, the links between Peers B and C 
are disconnected. The E-IISP link 70 connecting nodes 52, 54 remains intact. In 
particular, with reference to FIGS. 1 and 5, links 72, 74 are disconnected. Node 62 
is reconnected to node 164 via link 162. Node 58 is reconnected to node 60 via link 
160. Thus, links 160, 162 represent the new connections. Via the Hello protocol and. 
FSM, the nodes determine that the nodes on either side of the link are from the 
same peer group. Thus, they configure their ports as PNNI type ports as indicated 
in FIG. 5. 

Detailed Description Text (32) : 

Once the ports are re-configured as PNNI ports, the locally registered addresses 
are flushed from the topology database and corresponding PTSEs are flooded to the 
nodes within the peer group . 

Detailed Description Paragraph Table (1) : 

Term Definition ANSI American National Standards Institute ATM Asynchronous 
Transfer Mode CCITT Comite Consulatif International Telegraphique et Telephonique 
DS Database Summary DTL Designated Transit List E-IISP Enhanced Interim Inter- 
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Switch Signaling Protocol FDDI Fiber Distributed Data Interface FSM Finite State 
Machine IISP Interim Inter-Switch Signaling Protocol ILMI Interim Local Management 
Interface ITU International Telecommunications Union NNI Net to Network Interface 
OSPF Open Shortest Path First PGL Peer Group Leader PNNI Private Network to Network 
Interface PTSE PNNI Topology State Element PTSP PNNI Topology State Packet RCC 
Routing Control Channel SVC Switched Virtual Circuit UNI User to Network Interface 
VCC Virtual Channel Connection 

Current US Cross Reference Classification (2) : 
709/241 

CLAIMS: 

1. In an Asynchronous Transfer Mode (ATM) network having a plurality of nodes, said 
plurality of nodes configured to form one or more peer groups connected by one or 
more links, each node having a topology database and being capable of configuring 
each of its ports as either a Private Network Node Interface ( PNNI ) type port or an 
Enhanced Interim Inter-Switch Signaling Protocol (E-IISP) type port, a method of 
building ATM networks combining both PNNI and E-IISP schemes, said method 
comprising the steps of: 

determining, on each node connected to a remote node via a link, whether the node 
and its remote node are from the same peer group; 

configuring the port associated with the link as a PNNI type port if said node and 
its remote node are from the same peer group; 

configuring the port associated with the link as an E-IISP type port if said node 
and its remote node are not from the same peer group; 

transferring from the node to the remote node, all foreign addresses in the 
topology database of the node: 

registering said foreign addresses received by the remote node in the topology 
database of the remote node; and 

flooding said foreign addresses from the remote node to other nodes that are 
members of the peer group of the remote node. 

2. The method accprding to claim 1, wherein said step of determining comprises the 
steps of: 

executing a Hello protocol and associated Finite State Machine (FSM) of PNNI on 
each port configured as a non User to Network Interface (UNI) port; and 

extracting a peer group ID from Hello messages received from a remote node located 
on the other side of the link each port is connected to. 

3. The method according to claim 1, further comprising the step of executing a 
conventional Hello prot'ocol and PNNI Topology State Elements ( PTSE ) Finite State 
Machines (FSMs) of PNNI . 

4. The method according to claim 1, further comprising the step of executing a 
conventional Hello protocol and PNNI Topology State Elements ( PTSE ) Finite State 
Machines (FSMs) of PNNI on each port regardless of whether the port is configured 
as a PNNI type port or an E-IISP type port. 

5. The method according to claim 1, further comprising the step of changing the 
configuration of a port from a PNNI type port to an E-IISP type port in response to 
one or more changes to the configuration of the network. 
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6. The method according to claim 1, further comprising the step of changing the 
configuration of a port from an E-IISP type port to a PNNI type port in response to 
one or more changes to the configuration of the network. 



DOCUMENT-IDENTIFIER: US 620514 6 Bl 

TITLE: Method of dynamically routing to a well known address in a network 



Brief Summary Text (10) : 

The current standard solution for routing in a private ATM network is described in 
Private Network Node Interface ( PNNI ) Phase 0 and Phase 1 specifications published 
by ATM Forum. The previous Phase 0 draft specification is referred to as Interim 
Inter-Switch Signaling Protocol (IISP) . The goal of the PNNI specifications is to 
provide customers of ATM network equipment some level of multi-vendor 
interoperability. 

Brief Summary Text (36) : 

There is provided in accordance with the present invention, in an Asynchronous 
Transfer Mode (ATM) network having a, plurality of nodes, a network server 
application implemented on one of the nodes, a method of routing to a well known 
address, the method comprising the steps of sending an indication message 
containing a cost value on a periodic basis out on all Network to Network Interface 
(NNI) ports in the node that implements the network server application, receiving a 
message containing the cost value on a node, registering the well known address and 
a received cost value associated therewith on the port receiving the indication 
message if the well known address has not been previously registered, updating an 
existing cost value with the received cost value, incrementing the received cost 
value by one to yield a new cost value, forwarding an indication message containing 
the new cost value out on ports having a larger cost value registered therewith and 
on ports without a registered cost value if the received cost value is smaller than 
or equal to the smallest cost value associated with other NNI ports and routing a 
call request to the network server application, made by a user connected to a node, 
via the port with the smallest cost value associated therewith. 

Brief Summary Text (40) : 

There is also provided in accordance with the present invention, in an Asynchronous 
Transfer Mode (ATM) network having a plurality of nodes, a LAN Emulation 
Configuration Server (LECS) implemented one of the nodes, a method of routing to a 
well known address, the method comprising the steps of sending an indication 
message containing a hop count on a periodic basis out on all Network to Network 
Interface (NNI) ports in the node that implements the LECS, receiving a message 
containing the hop count on a node, registering the well known address and a 
received hop count associated therewith on the port receiving the indication 
message if the well known address has' not been previously registered, updating an 
existing hop count with the received hop count, incrementing the received hop count 
by one to yield a new hop count, forwarding an indication message containing the 
new hop count out on ports having a larger hop count registered therewith and on 
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ports without a registered hop count if the received cost value is smaller than or 
equal to the smallest hop count associated with other NNI ports and routing a call 
request to the LEGS, made by a user connected to a node, via the port with the 
smallest hop count associated therewith. 

Detailed Description Text (10) : 

If the well known address is not registered on the NNI port that the message came 
in on, then the node registers it and assigns the hop count to it. If the well 
known address is already registered to the NNI port, the existing hop count 
associated with the registered address is updated with the hop count just received. 



Detailed Description Paragraph Table (1) : 

Term Definition ANSI American National Standards Institute ATM Asynchronous 
Transfer Mode BUS Broadcast and Unknown Server CCITT Comite Consulatif 
International Telegraphique et Telephonique FDDI Fiber Distributed Data Interface. 
FSM Finite State Machine IE Information Element IISP Interim Inter-Switch Signaling 
Protocol ILMI Interim Local Management Interface IP Internet Protocol ITU 
International Telecommunications Union LAN Local Area Network LANE LAN Emulation 
LEG LAN Emulation Glient LEGS LAN Emulation Gonf iguration Server LES LAN Emulation 
Server LNNI LAN Emulation Network to Network Interface LUNI LAN Emulation User to 
Network Interface MAG Media Access Control NNI Net to Network Interface PNNI 
Private Network to Network Interface PTSE PNNI Topology State Element PTSP PNNI 
Topology State Packet PVC Permanent Virtual Circuit RCC Routing Control Channel SVC 
Switched Virtual Circuit SVCC Switched Virtual Channel Connection TLV Type Length 
Value UNI User to Network Interface VCC Virtual Channel Connection 

Current US Gross Reference Classification (2) : 
709/238 

Current US Gross Reference Classification (3) : 
709/239 
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DOCUMENT-IDENTIFIER: US 6141325 A 

TITLE: Paradigm for enabling interoperability between different subnetworks 
Brief Summary Text (8) : 

In order to enable topology updates, a rigid standard or paradigm for the 
topological data has to specify a fixed structure for the messages (syntax) , as 
well as how they should be understood by network control (i.e., its semantics). The 
most prominent examples for this paradigm is the Private Network-to-Network ( PNNI ) 
standard for inter-network control of asynchronous transfer mode (ATM) , and the 
Open Shortest Path First (OSPF) standard for Internet intra-domain routing. In 
other words, the network controller (NC) must know the standards and control format 
for each sub-network within the network. Often times the various standards of the 
sub-networks vary greatly thus requiring the NC at each node to replicate many 
standards and protocols. 

Brief Summary Text (12) : 
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The practice of topology aggregation is used in most of the standards and 
implementations of scalable networks. Topology aggregation refers to the reduction 
of complex topological data into smaller and simpler data which approximates the 
original data. A few examples of topology aggregation are the single level 
aggregation of Decnet (areas/hosts) , the two level aggregation of IP (autonomous 
systems/networks/hosts), and the unbounded aggregation of the PNNI standard for 
ATM. 

Detailed Description Text (4) : 

In addition to the high-level topology map, each node has to maintain information 
on the internals of each sub-net, since paths through different sub-nets may have 
very different characteristics. Instead of having to standardize the data 
maintained for each sub-net (as done in prior art) each node in the high-level 
topological view has a software agent 306 associated with it, residing at the local 
memory of network control (NC) at each node, as part of the topology database. This 
agent 306 is programmed according to the specific properties of the sub-net it 
represents and comprises its code and its storage 307. All information the network 
control at Node Al knows regarding nodes in other sub-nets is acquired through 
standardized interfaces of their respective agents (i.e., a "black box" approach). 
Topology updates for other nodes travel in the network in some vendor-specific 
format, with very few standard fields, amongst which a logical address that enables 
network control at Al to direct the update to the appropriate agent. Upon receipt 
of an update, the agent 306 processes it, and updates its internal data structure 
storage 307. 

Detailed Description Text (6) : 

Prior to operation, the network must obtain the agent code for each node. When a 
new node joins the system, it lets its neighbors know its .type., which determines 
the agent which represents it. The type of a node may be its vendor (e.g., IBM), or 
a standard it complies to (e.g., PNNI low level node), a type of a supernode or 
domain may be a network operator (e.g., AT & T or America Online. SM.) which runs 
the sub-net, a standard (e.g., PNNI aggregated topology), or a sub-net type (e.g., 
LAN, RING, etc.). More often than not, the neighbors will already have agents of 
the same type. Hence they will already have the code of the new node's agent, and 
will not need it to be shipped to them. Otherwise, the new node will update the 
rest of the network with the code of its agent, encoded in some hardware 
independent standard format, such an JAVA. 

Detailed Description Text ( 9) : 

Referring now to FIGS. 3 and 4, FIG. 3 shows a chart detailing the functions of an 
agent and FIG. 4 is a representative diagram. Specifically, each agent comprises a 
Find - Address function,- a Minimum Delay function," a Minimum Cost" function,- a 
Topology Update function, and a Setup Message function. Each are discussed in more 
detail below. 

• Detailed Description Text (10) : 

The Find Address' function (FindAddress) avoids the need for a standard address 
format. The NC simply asks all of its node agents if a given address is inside 
them, until one of the agents takes responsibility for the address. Nodes complying 
with a hierarchical scheme may look at the relevant prefix of the input to decide 
(for example, "any address of the form 2.3.*.* is mine"). Other nodes may just have 
a list or a range of all addresses supported by them. Even here, the current scheme 
is more flexible than other inter-networking addressing schemes (e.g., the PNNI 
interface of the ATM forum or address resolution in current internet protocol (IP) 
and next generation IP (IPng)). 

Detailed Description Text (13) : 

Referring again to FIG. 3, the agents' Minimum Delay (MinDelay) function is used to 
calculate an appropriate path to route the data packet to the sub-net containing 
the requested destination address. This path is calculated based on such factors as 
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bandwidth requirements, quality of service (QoS) requirements, and propagation 
delay. The various sub-nets .or supernodes may choose different schemes for 
aggregating the topology. For example, some will have full knowledge of their 
internal sub-net's topology '{no aggregation, but still independent format), some 
will have PNNI or IDRP aggregation, and some even simpler structures, not requiring 
updates at all. For example, a sub-net that accepts any 64 Kbps connection with 
fixed QoS, and only guarantees some fixed upper bound on the delay (any connection 
request with more demanding requirements is rejected by returning infinite delay) 
does not need topology updates at all. 

Current US Cross Reference Classification { 1 ) : 
709/242 
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DOCUMENT-IDENTIFIER: US 6085238 A 

** See image for Certificate of Correction ** 

TITLE: Virtual LAN system 

Brief Summary Text (19) : 

On the other hand, in a connection-oriented ATM (asynchronous transfer mode) 
system, development of LAN emulation corresponding to the conventional LAN bridge, 
MPOA for providing a multiprotocol router on LAN emulation, an IP-over-ATM system 
for passing the IP on ATM, an IP-over-RSVP system for passing the RSVP on ATM, an 
IP switching system for switching only the IP on ATM, a 1 -PNNI system for routing 
internet protocols on a private signaling protocol between ATM switches, and ATM- 
native transmission quality guarantee (QoS) technique is also pursued. 

Brief Summary Text (35) : 

When the servers managed in a centralized manner in the network center are accessed 
or overlapped segments across segments are formed, communication traffic across 
layer 2 LAN switch segments increases. Then, a switch called a layer 3 LAN switch 
filtered based on the routing protocol address or the protocol type has been 
developed for floor line concentrators. With the layer 3 LAN switch, layer 3 
virtual network segments based on logically defined protocol addresses 
independently of physical wiring like MAC addresses or ports are formed and may be 
called virtual subnet. Since the layer 3 LAN switch contains a router function, 
traffic across layer 2 subnets can also be directly switched not via the main 
router; subnets rather than flat subnets can be classified according to management 
policy or a fire wall for the routing protocol can be provided for enhancing 
security. If the layer 3 LAN switch is formed in an MPOA system on ATM LAN 
simulation, standardization is not yet complete, thus the layer 3 LAN switch may be 
installed under specifications proper to each vendor and limited transmission 
quality guarantee (QoS) is also provided. A backbone LAN system of routing between 
ATM switches in an I -PNNI system and using a layer 3 LAN switch as the edge LAN 
switch is also developed. 

Detailed Description Text (12) : 

When ports differ although a client address match is found as a result of the 
virtual group identification for a terminal move, the virtual group identification 
section 1 outputs a port change message, the virtual group learning section 3 sends 
a topology change message to a virtual group distributed management section 9, 
which then learns in response to the topology change and dynamically updates the 
virtual group routing table 8. 

Detailed Description Text (13) : 

By the way, if the connection ports of virtual groups are distributed over the LAN 
switches distributed over the network and the virtual group registration tables 2 
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and the virtual group routing tables 8 are distributed over the LAN switches, the 
virtual group identification section 1 of each LAN switch collates input port 41 . 
. . and the packet source address with the virtual group registration table 2 and 
detects topology change such as a terminal move, and the virtual group learning 
section 3 automatically updates the virtual group registration table 2 and the 
virtual group routing table 8. 

Detailed Description Text (269) : 

When a port change message is output when ports differ although a client address 
match is found as a result of the virtual group identification for a terminal move, 
the virtual group learning section 316 sends a topology change message to the 
virtual group distributed management section 303, which then learns in response to 
a user environment message according to a user request and the topology change and 
dynamically updates the virtual group routing table 308. 

Detailed Description Text (271) : 

The virtual group learning section 316 dynamically executes automatic configuration 
management for a terminal move. That is, when ports differ although a client 
address match is found as a result of the virtual group identification for a 
terminal move, the virtual group learning section 316 outputs a port change message 
for dynamically updating the virtual group registration table 301, thereby 
executing automatic configuration management automatically. 

Detailed Description Text (273) : 

In the configuration in which the connection ports of virtual groups are 
distributed to the switches distributed over the network and the virtual group 
registration tables 301 and the virtual group routing tables 308 are distributed to 
the switches, the virtual group identification section 309 of each switch S has the 
virtual group learning section 316 for collating input port 341 . . . and the 
packet source address with the virtual group registration table 301, detecting 
topology change such as a terminal move, and automatically updating the virtual 
group registration table 301 and the virtual group routing table 311. The virtual 
group distributed management sections 303 of the switches S as virtual group agents 
VA dynamically manage the virtual group registration tables 301 and the virtual 
group routing tables 308 distributed to the switches S in coordination with each 
other based on topology change detection of a terminal move, a switch S move, etc., 
whereby virtual groups can be shared among the switches S in the network. 

Detailed Description Text (391) : 

The optimum connection port address is entered in the virtual group 
registration/virtual group routing table shown in FIG. 61(a) as the routing 
connection port. That is, in the distributed switch configuration, another switch 
is cascaded to a port of one switch, thus for the port to which a switch is 
connected, the connection port becomes a port name corresponding to the optimum 
route reading to the home switch to which the terminal is connected. When a port 
change message is output when ports differ although a client address match is found 
as a result of the virtual group identification for a terminal move, the intranet 
virtual group learning/identification section 4 90 sends a topology change message 
to the virtual group distributed management section 488, which then learns in 
response to a user environment message according to a user request and the topology 
change and dynamically updates the virtual group routing table 485. 

Detailed Description Text (393) : 

The virtual group learning section 487 dynamically executes automatic configuration 
management for a terminal move. When ports differ although a client address match 
is found as a result of the virtual group identification for a terminal move, the 
virtual group learning section 16 outputs a port change message and the intranet 
virtual group learning/identification section 4 90 dynamically updates the virtual 
group registration table, thereby executing automatic configuration management 
dynamically. 
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Detailed Description Text (395) : 

In the configuration in which the connection ports of virtual groups, namely, input 
ports 4 94a ... of an input access control section 494 of the branch line 
concentration unit 414 are distributed to the distributed network service equipment 
411 distributed over the network and the virtual group registration tables 486 and 
the virtual group routing tables 4 85 are distributed to the distributed network 
service equipment 411, the virtual group identification section 487 of each switch 
has the intranet virtual group learning/identification section 4 90 for collating 
input port 494a . . . and the packet source address with the virtual group 
registration table 486, detecting topology change such as a terminal move, and 
automatically updating the virtual group registration table 486 and the virtual 
group routing table 485. The virtual group distributed management sections 488 of 
the distributed network service equipment 411 as virtual group agents dynamically 
manage the virtual group registration tables 486 and the virtual group routing 
tables 485 distributed to the switches in coordination with each other based on 
topology change detection of a terminal move, a switch move, etc., whereby virtual 
groups are shared among the distributed network service equipment 411 in the 
network. 

Current US Original Classification ( 1) : 
709/223 ' 

Current US Cross Reference Classification (2) : 
709/243 
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DOCUMENT-IDENTIFIER: US 6021117 A 

TITLE: System for parameter analysis and traffic monitoring in asynchronous 
transfer mode (ATM) networks 



Brief Summary Text ' (33)": -. - - 

Additionally in accordance with a preferred embodiment of the present invention the 
function which the ATM connection serves includes at least one of the followingj_ 
PNNI, signaling, LAN-emulatron . 

Detailed Description Text (13) : 

application or function served, which may typically comprise one of the followingj_ 
PNNI , signaling, LAN-emulation, or another appropriate function. 

Detailed Description Text (21) : 

function served by the ATM connection such as, for example, a type of application 
service being provided by the ATM connection, such as, for example, LAN-emulation 
or PNNI. 



Detailed Description Text (37) : 

function served by the ATM connection such as, for example, a type of application 
service being, provided by the ATM connection, such as, for example, LAN-emulation 
or PNNI. 
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Detailed Description Text (112) : 

The usage of the VC : PNNI, Signaling, LANE Control/Configuration, LANE 802.3 Data 
Direct, LANE 802.5 Data Direct, LANE 802.3 Multicast, LANE 802.5 Multicast, or 
"other". 

Detailed Description Text (152) : 

4. The tables are updated whenever a new ATM address is identified, i.e., when a 
new VC is created and either of the two hosts communicating on this VC have not yet 
been registered in the host table. 

Current US Cross Reference Classification (2) : 
709/224 

CLAIMS : 

29. A method according to claim 5 wherein said function which said ATM connection 
serves comprises PNNI . 
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DOCUMENT-IDENTIFIER: US 6002674 A 

TITLE: Network control system which uses two timers and updates routing information 
Brief Summary Text (3) : 

The present invention relates to the update of routing control information. In a 
network where a plurality of switches each having an ATM (Asynchronous Transfer 
Mode) interface are interconnected, the switches make SVC (Switched Virtual 
Circuit) connection with each other by referring to the information produced by 
exchanging PNNI routing control packets (Hello packets and PTSP (PNNI Topology 
State Packets) ) . 

Brief Summary Text (5) : 

PNNI (Private Network to Network Interface) Specification VI. 00 (hereafter called 
PNNI) from The ATM Forum Technical Committee describes the interface via which the 
switches in an ATM network make SVC connections. This PNNI contains information on 
the following: 

Brief Summary Text ( 6) : 

(a) PNNI routing control packet exchange method and exchange information 
Brief Summary Text (8) : 

The PNNI specifies that topology information be required for generating routing 
information. The topology information refers to network component information or 
state information on the network components such as lines and switches. This 
information is obtained by exchanging PNNI routing control packets the switches 
within the network. 



Brief Summary Text (11) : 

(b) Routing information is generated when a PNNI routing control packet is received 



h e b b eg b cc e 



Record List Display 



Page 5 of 1 1 



Brief Summary Text (12): 

(c) Topology information is generated from a received PNNI routing control packet 
and, at a specified interval, routing information is generated. 

Brief Summary Text (14): 

In case of (a), a delay in setting up a call from an originating terminal degrades 
the overall system performance. In case of (b) , there is a possibility that a large 
number of PNNI routing control packets are received when a line or a switch in the 
network fails or when a condition (repetitive errors and error recovery processing) 
occurs. This condition causes routing information to be updated frequently, 
affecting the system performance. In case of (c) , PNNI routing control packet 
information exchanged in the network is not reflected on the routing information 
immediately. Therefore, when an SVC connection request is received before routing 
information is updated by a PNNI routing control packet, the connection request may 
fail; conversely, when an error is already recovered but the routing information is 
not yet updated accordingly, the connection request may fail. 

Brief Summary Text (17): 

To achieve this objective, this system has two timers: the first timer sends the 
time-out signal at a specific interval and the second timer at an interval shorter 
than that of the first timer. The first timer sends the time-out signal at the 
longest interval for updating the routing information when the network is in the 
normal state. The second timer sends the time-out signal at the shortest interval 
for updating the routing information. The second timer generates the time-out 
signal at this interval to prevent a large number of PNNI routing control packets 
from being generated and the system performance from being degraded when a line or 
a switch in the network fails or when a line unbalance condition (repetitive errors 
and error recovery processing) occurs. 

Detailed Description Text (3) : 

The first timer updates routing information immediately when it times out. That is, 
the first timer updates routing information at least once at a specified interval. 
On the other hand, the second timer updates routing information when it times out 
and if the significant-change detection flag is on at that time. This means that 
the interval of the second timer is the shortest interval at which routing 
information is updated. The significant-change detection flag is set to on only 
when a received PNNI routing control packet indicates that the registration of the 
address or the link of a terminal or the link of an ATM switch has been changed. 

Detailed Description Text (4): 

A system in this embodiment generates or updates routing information, not when a 
call request is received from a terminal, but when the first or the second timer 
times out. This eliminates a delay in setting up a call. When the system receives a 
large number of PNNI routing control packets, the system does not have to update a 
large volume of routing information because it updates the information at the 
interval of the second timer. This prevents the overall system performance from 
being degraded. In addition, a significant change, such as a change in terminal or 
ATM switch addresses or a change in link data, is reflected on routing information 
when the second timer times out. This allows a call from a terminal to be connected 
successfully. 

Detailed Description Text (id) : 

The first timer 21 updates the routing information 24 at a specified interval. This 
interval is the longest interval at which the routing information 24 is updated. 
The routing information 24 is updated at least once at this interval even when the 
network is in the stable state (i.e. there is no change in terminal address and 
switch address, and there is no change in link configuration in which the switches 
are connected to each other) . 
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Detailed Description Text (11) : 

On the other hand, the second timer 22 updates the routing information 24 at the 
shortest interval. A line failure, a switch failure, or a unbalance condition 
(repetitive errors and error recovery processing) on the network may generate a 
large number of PNNI routing control packets. This in turn causes the routing 
information to be updated often, affecting the overall system performance. The 
second timer 22, the shortest-interval time timer, prevents this condition. 

Detailed Description Text (14): 

The address/link information management module 31 manages the address information 
of the ATM switch 100 and link information denotes link configuration in which the 
switches are connected to each other, and the line speed and transmission delay 
thereon) and sends a PNNI routing control packet containing address information and 
link information to another ATM switch 300. 

Detailed Description Text (15): 

The topology information management module 32 manages topology information which is 
sent from another ATM switch 300 as PNNI routing control packets. Topology 
information is information on terminal addresses, switch addresses, line 
attributes, status, and so forth. Terminal addresses are those of the terminals 
(e.g., terminal 200 in FIG. 2) connected to an ATM switch (e.g., ATM switch 100 in 
FIG. 2). Switch addresses are those of the switches (e.g., ATM switch 100 or 
another ATM switch 300) con:^igured in the network. Line attributes and status data 
denotes link configuration in which the switches are connected to each other and so 
forth. The line attributes and status data are stored in the address/link 
information management module 31 as link information. 

Detailed Description Text (16) : 

The topology information management module 32 sends or receives PNNI routing 
control packets to or from another ATM switch 300 over the communication line to 
get topology information on each ATM switch and to keep topology information up to 
date. Topology information which is kept up to date in this manner keeps the ATM 
switch 100 informed of which ATM switches and terminals are available for use. 

Detailed Description Text (17) : 

The significant change detection module 33 -turns on the flag 33a upon detection of 
a pre-determined state in the network. In this embodiment, the significant change 
detection module 33 turns on the flag 33a (a) when the address information or link 
information of the ATM switch 100 is changed or (b) when a PNNI routing control 
packet indicating that the address information or link information of another ATM 
switch 300 is changed. Note that address information and link information may 
change according to how they are used for control. 

Detailed Description Text (19) : 

The ATM switch 100 exchanges PNNI routing control packets with other ATM switches 
to keep address information and link information up to date for use as topology 
information. And, based on this topology information, the ATM determines a route to 
each terminal or switch in the network and keeps this routing information as the 
routing information 24. When the ATM receives an SVC connection request, it 
references the routing information 24 to find the best route to the destination 
terminal or switch. 

Current US Cross Reference Classification (2) : 
709/242 

Other Reference Publication (1) : 

af -pnni -0055. OOP Letter Ballot, ATM Forum Technical Committee, pp. 36-37, 15-17, 
357-364 and 40. 
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CLAIMS: 

2. A network control system which controls switched virtual connection on a 
network, containing a plurality of interconnected switches each having an 
asynchronous transfer mode interface, by referencing routing information generated 
by exchanging PNNI routing control packets, the network control system comprising: 

a significant change detection module setting a significant change detection flag 
to on upon detecting a pre-determined condition on the network; 

a first timer generating a time-out signal at a specific interval; 

a second timer generating a time-out signal at an interval shorter than that of the 
first timer; and 

a routing information update control module having the routing information, 
unconditionally updating corresponding routing information upon receiving the time- 
out signal from the first timer, and updating the routing information upon 
receiving the time-out signal from the second timer only if the significant change 
detection flag is on. 



Classification 
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DOCUMENT-IDENTIFIER: US 5903559 A 

** See image for Certificate of Correction ** 

TITLE: Method for internet protocol switching over fast ATM cell transport 
Detailed Description Text (23) : 

Setting up and controlling switched paths is done using "inferred" IP signaling. 
This approach allows the reuse of a wide-array of existing IP protocol software . 
with minimal- modifications". Additional ATM hardware and software features are 
reused as much as possible with our IPSOFACTO method. This includes using ATM level 
hardware multicast for IP multicast as well reusing PNNI topology tables for 
routing and using UPC policies and CAC for RSVP. 

Detailed Description Text (59) : 

Multicast OSPF (MOSPF) uses the OSPF unicast routing protocol (link-state) instead 
of RIP. This protocol is not widely used, but is attractive because it shares the 
same underlying unicast routing protocol as native ATM, namely PNNI . 

Detailed Description Text (62) : 

With these protocols in mind, we can now discuss how IP multicast situations work 
with our inventive method. In the first situation, the IP protocols are run 
independent of the native ATM protocols. In the second situation the underlying 
unicast ATM routing protocol ( PNNI ) is reused for topology acquisition and the 
multicast IP is run on top of that. 



Detailed Description Text (90) : 
Multicast IP/PNNI Extensions 
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Detailed Description Text (91) : 

In the above discussion it was assumed that IP multicast routing will be run on top 
of ATM hardware--independent of the ATM routing. However, it is possible to reuse 
the existing ATM routing protocol ( PNNI ) for the route selection without invoking 
PNNI signaling for route reservation. Since MOSPF uses the same underlying link- 
state protocol as PNNI it would be instructive to see how MOSPF works and then show 
our inventive modifications (if necessary) to PNNI which make it suitable for IP 
multicast . 

Detailed Description Text (94): 

In ATM, the same link-state topology exchange protocol exists and is hierarchical. 
So one option is to propagate the IP-multicast group membership for the local link 
as a part of the PNNI protocol exchange. This may be considered a layering 
violation but the topology/link-state exchange protocol is independent of the route 
computation IP-multicast routing should be supported "native" and in a peer-to-peer 
fashion with PNNI route selection except the fact that latter needs signaling and 
the former does nott. Consequently, our scheme for IP-multicast using PNNI topology 
acquisation scheme is summarized as follows. 

r 

Detailed Description Text (95) : 

When the first-hop router receives a (src, group) packet it computes the shortest 
path tree computation using the PNNI topology information. Since this information 
is hierarchical, the router will be able to compute the complete sub-tree undereath 
it and neighboring routers in the same peer group. PNNI uses source routing for its 
signaling so the entire path is forwarded in the signaling message in the existing 
ATM stack. 

Detailed Description Text (97) : 

The IPSOFACTO implementation assumes a flat PNNI topology. The first-hop router 
receives the packet and computes a shortest path tree. For each outgoing branch it 
picks up an unused VP/VC on the port leading to the switch (next-hop router) . It 
then creates a 1-2-m entry in its VP/VC table and starts soft-state on that VP/VC. 
The path is torn down if there is no activity for a period of time. 

Detailed Description Text (98): 

A problem with using the augmented PNNI approach (link state also contains group 
membership information) is that every change in the group members may trigger a 
flood of PNNI messages through the network. This is overcome in the hierarchical 
PNNI by updating group membership information only in a sub-domain and letting the 
rest of the network be blind to the actual members in each sub-domain. 

Detailed Description Text (101) : 

If the fixed host is mobility-aware, i.e., it can receive location updates, (route- 
optimization extensions in IPv6) then the above doglegged ATM circuit will time out 
after the fixed host sends packets using the mobile's foreign address (and setting 
up a switched flow to the foreign address ) . Consequently, if the fixed host is 
mobility unaware, then for fixed to mobile flows when the mobile is moving, the 
home agent will receive a location updatefrom the mobile via a default IP PVC. Note 
that it is not necessary to transport this update over a switched path because the 
total number of packets for the update will not be a very large number. 

Detailed Description Text (111) : 

In this situation, where there is mobility-aware-ATM, we let the original path be 
set up by mobile IP and then switched using the IPSOFACTO method previously 
described. When handoff occurs, however, the same mechanisms as were used with the 
mobile ATM handoff will be used to determine the crossover point and switch flows 
at that point. This requires that the mobile IP router as well as the mobile ATM 
module share the same topology tables that PNNI will produce. 
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Detailed Description Text (123) : 

For the generic IP-multicast situation, RESV merges will need to be done in the 
routed path, which will create 1-2-m ATM multicast VCs with the appropriate 
resource reservation parameters as well as set token buckets for each VC at the 
line interface card for monitoring and marking excess traffic. PATH messages will 
be forwarded based on the IP-mcast routing protocol (Dense mode or Sparse mode PIM 
or PNNI -augmented) . 

Current US Cross Reference Classification (5) : 
709/236 
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DOCUMENT-IDENTIFIER: US 5828844 A 
TITLE: Internet NCP over ATM 

Detailed Description Text (5) : 

Although both the IP and ATM routing protocols employed in the Classical IP model 
may determine reachability information for the same hosts, they run independently 
of one another. For example, IP routers run routing protocols such as RIP and OSPF 
exchange reachability information pertinent to IP destinations. Likewise, ATM 
switches run independent protocols such as PNNI to determine ATM network topology 
and address reachability. Typically, separate IP routers and ATM switches are 
provided. In fact, many networking scenarios even employ different IP and ATM 
network topologies. 

Detailed Description Text (14): 

Recently, a single device known as an IP switch has been developed. An IP switch 
integrates a conventional router and ATM switch to route IP over ATM networks much 
more efficiently than in the traditional model, which employs distinct devices. The 
IP over ATM model may be substantially simplified if the router and the ATM switch 
physically reside in the same device, as illustrated in FIG. 3. As previously 
mentioned, when the functionality of an ATM switch and an IP router reside on 
separate devices, the ATM switch does not have knowledge pertaining to routing and 
addressing at the IP layer. In contrast, when the functionality of an ATM switch 
and an IP router are merged onto the same device, it becomes possible to further 
integrate routing at the IP level into routing at the ATM level. For example, a 
perfect topology match is achieved when a layer two node (an ATM switch) is 
physically integrated into a layer three node (an IP router) . Although this 
configuration does not eliminate the problem of matching an IP address with its 
corresponding ATM address, the elimination of the topological mismatch creates the 
opportunity to use a single routing protocol for routing at both the IP and ATM 
layers. An Illustrative protocol that may serve in this capacity includes I -PNNI 
(see R. Callon, Relationship Between MPOA and I -PNNI, April 1996, ATM Forum 96- 
0352), which has been submitted to the ATM Forum to integrate routing at the IPO 
layer into PNNI . I -PNNI facilitates the bootstrapping and ongoing operation of 
Internet routing protocols and associated packet forwarding protocols over an ATM 
network. 

Detailed Description Text (23) : 

As seen in FIG. 3, the proxy server 53 functions in cooperation with an Internet 
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network control point (NCP) 54. The NCP 54, which is analagous to known network 
control points used in telephone networks that employ intelligent call processing, 
is the master database of the network which stores end-point information such as 
the correspondence between ATM, IP and MAC addresses, QoS requirements, special 
security filters, and billing properties. End-points can access the NCP 54 via the 
proxy server 53 to retrieve information and update the database as appropriate. 
That is, the proxy server 53 functions as a client interface to the NCP 54. The NCP 
54 also may be updated in an automatic fashion by the individual IP switches in the 
network, such as when an endpoint registers or unregisters an IP to ATM address 
correspondence or a particular QoS. 

Detailed Description Text (26) : 

The address database may also perform additional functions such as: receiving 
updated IP-ATM address registrations from clients or other address databases; 
receiving IP-ATM address deregistration requests from clients or other address 
databases; adding or deleting IP to ATM address correspondences from the database; 
receiving address queries from clients or other address databases; forwarding 
address query requests to clients or other address databases; forwarding address 
query responses; and receiving provisioned end-point information updates from the 
Internet NCP. 

Detailed Description Text (27) : 

The address databases may be implemented in any convenient manner. Two possible 
implementations are a fully distributed implementation and a fully duplicated 
implementation. In the fully distributed approach, each IP switch only maintains an 
address database for those end-points that access the Internet at that particular 
IP switch. Accordingly, there is no need for synchronization among different 
address databases in different IP switches. For example, when a source end-point 
sends an address query to its IP switch regarding a destination end-point and the 
IP to ATM address correspondence is not found in the queried IP switch, the switch 
will forward the request only to the IP switch responsible for the destination end- 
point. In a fully distributed arrangement, the Internet NCP serves as the master 
database that stores all provisioned information for the network, including the IP 
to ATM address correspondences. When a change in the address database of an IP 
switch occurs (due to a host disconnecting from the IP switch, for example), the 
same change is forwarded to the Internet NCP to update the master database. 
Similarly, when the Internet' NCP is modified by the service provider or the user, 
the appropriate individual address database (s) within the. IP switch (es) will be 
updated accordingly. 

Current US Original Classification ( 1 ) : 
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File: USPT 



Nov 30, 2004 



DOCUMENT-IDENTIFIER: US 6826447 B2 

TITLE: Process for the creation and enrichment of a data base of a post sorting 
system 



Abstract Text (1) : 

This invention relates to a process for automatically creating and enriching a data 
base in a system for sorting mail items linked, through an INTRANET communications 
network, to computer stations of addressees of these mail items and comprising 
reading means for recognizing postal data printed on these mail items, processing 
means in order, in relation with a work data base comprising identification data 
relative to the addressees of the mail items, to identify the individual addressee 
of a determined mail item, and sorting means for allocating this mail item to the 
addressee thus identified, process in which there is firstly automatically sent to 
the electronic mail address of each addressee, a determined electronic message 
requesting him to be connected on a WEB page of the sorting system in order to 
enter personal identification data, and, once entered, these data are then 
automatically stored in a temporary data base for comparison with the data present 
in the work data base in order thus to ensure automatic update thereof. 
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(57) ABSTRACT 

This invention relates to a process for automatically creating 
and enriching a data base in a system for sorting mail items 
linked, through an INTRANET communications network, to 
computer stations of addressees of these mail items and 
comprising reading means for recognizing postal data 
printed on these mail items, processing means in order, in 
relation with a work data base comprising identiiicatioa data 
relative to the addressees of the mail items, to identify the 
individual addressee of a determined mail item, and sorting 
means for allocating this mail item to the addressee thus 
identified, process in which there is firstly automatically sent 
to the electronic mail address of each addressee, a deter- 
mined electronic message requesting him to be connected on 
a WEB page of the sorting system in order to enter personal 
identification data, and, once entered, these data are then 
automatically stored in a temporary data base for compari- 
son with the data present in the work data base in order thus 
to ensure automatic update thereof. 
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File: USPT 



Jun 10, 2003 



DOCUMENT-IDENTIFIER: US 6578085 Bl 

TITLE: System and method for route optimization in a wireless internet protocol 
network 



Abstract Text (1) : 

A system and method for route optimization in- a wireless Internet Protocol (IP) 
network . The system and method send, to a home agent, a data packet; transmit, to a 
mobile node, the data packet using a first address; maintain a list of 
correspondent nodes associated with the mobile node; send, to the correspondent 
node, a binding update message; and transmit, directly to the mobile node, 
subsequent data packets using the first address. The system and method 
additionally: transmit, to a home agent, a registration request comprising a new 
address ; transmit, to a mobile node, a registration reply in response to the 
registration request; compare the new address to an old address ; if the new address 
and the old address are not equal, transmit, to the correspondent node, a binding 
update message; transmit, to the home agent, a binding acknowledgment in response 
to the binding update message; and transmit, to the mobile node, all subsequent 
messages via the new address . 
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A system and method for route optimization in a wireless 
Internet Protocol (IP) network. The system and method 
send, to a home agent, a data packet; transmit, to a mobile 
node, the data packet using a first address; maintain a list of 
correspondent nodes associated with the mobile node; send, 
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-allyrtransmitrto a Home agent, a registration request com- 
prising a new address; transmit, lo a mobile node, a 
registration reply in response to the registration request; 
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address and the old address are not equal, transmit, to the 
correspondent node, a binding update message; transmit, to 
the home agent, a binding acknowledgment in response to 
the binding update message; and transmit, to the mobile 
node, all subsequent messages via the new address. 
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TITLE: Method and system for maintaining reserve command relationships in a fibre 
channel network 



Abstract Text (1) : 

A method and system for maintaining a unique reserve command relationship between 
an initiator and a target device in a Fibre Channel network across network address 
changes after a break in communication. The present invention maintains triplet 
tables containing data triplets, comprised of the network address, the port name, 
and the node name, for each initiator and each target device. Following a break in 
network communication that results in the network address of an initiator and/or a 
target device changing, the method of the present invention updates the recorded 
network addresses for the initiators and the target devices, maintains any 
previously-existing unique reserve command relationships and continues with I/O 
transmission. Although the network address of an initiator may change, the node 
name and port name of the initiator will remain the same. By comparing the 
initiator port name and node name contained in a reserve table maintained in the 
target device to the node name and port name corresponding to the now updated 
network address for an initiator with which it was in a unique reserve command 
relationship prior to the break in communication, a target device can then simply 
update the network address for the initiator and no disruption in I/O traffic will 
result . 
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ABSTRACT 



A method and system for maintaining a unique reserve 
command relationship between an initiator and a target 
device in a Fibre Cbaimel network across network address 
changes after a break in communication. The present inven- 
tion maintains triplet tables containing data triplets, com- 
prised of the network address, the port name, and the node 
name, for each initiator and each target device. Following a 
break in network communication that results in the network 
address of an initiator and/or a target device changing, the 
method of the present invention updates the recorded net- 
work addresses for the initiators and the target devices, 
maintains any previously-existing unique reserve command 
relationships and continues with I/O transmission. Although 
the network address of an initiator may change, the node 
name and port name of the initiator will remain the same. By 
comparing the initiator port name and node name contained 
in a reserve table maintained in the target device to the node 
name and port name corresponding to the now updated 
network address for an initiator with which it was in a 
unique reserve command relationship prior to the break in 
communication, a target device can then simply update the 
network address for the initiator and no disruption in I/O 
traffic will result. 

32 Claims, 4 Drawing Sheets 



FIBRE CHANNEL 



4-^ 


NETWORK 


NETWORK LINK 


NETWORK 


^16 




ADDRESS 1 


/ 


ADDRESS 2 





|1 INITIATOR . TARGET DEVICE 

NODE NAME: A NODE NAME: B 

PORT NAME: A PORT NAME: B 



i 


]\ INITIATOR TARGET TRIPLET TABLE 


l\ TARGET INITIATOR TRIPLET TABLE 




NETWORK 
ADDRESS 


NODE 
NAME 


PORT 
NAME 


NETWORK 
ADDRESS 


NODE 
NAME 


PORT 
NAME 




2 


B 


6 


1 


A 


A 


18-^ 














o 
o 


0 

o 


o 
o 


o 
o 


0 

o 


o 
o 



<f reeform Search 



Freeform Search 



Page 1 of 1 



Database: 



Term: 



I US Pre-Grant Publication Full-Text Database 



US Patents Full-Text Database 



US OCR Full-Text Database 
EPO Abstracts Database 
JPO Abstracts Database 
Denwent World Patents Index 
IBM Technical Disclosure Bulletins 



Ll and ( (replace$ or updat$) with (address$ adj2 
compar$ ) ) 



Display: |10 | Documents in Display Format : |KWIC | Starting with Number 
Generate: O Hit List ® Hit Count C Side by Side O Image 



Search History 



DATE: Wednesday, February 16, 2005 Printable Copy Create Case 

^ LfO A 7 Hit Set 



Name Query 
side by 
side 




Count Name 
result set 



DB=USPT; PLUR=YES; OP=ADJ 
Lie Ll and ((replaceS or updat$) with (address$ adj2 compar$)) 27 y jJO ..- 



L9 


Ll and ((replaces or updat$) with addressS with compar$).ab. 


- 3 


L9 


L8 


Ll and ((replace$ or updatS) with addressS with compar$).ab. 


3 


L8 


L7 


Ll and ((replaceS or updatS) with addressS with compar$).ab. 


3 


L7 


L6 


Ll and ((replaces or updatS) with addressS with comparS) 


125 


L6 


L5 


Ll and ((replaceS or updatS) with (old adjl addressS) with (new adj 1 


4 


L5 


addressS)) 




L4 


Ll and ((replaceS or updatS) with old with new with addressS) 


51 


L4 


L3 


Ll and ((replaceS or updatS) with comparS with old with new with 


2 


L3 


addressS) 




L2 


Ll and ((replaceS or updatS) with old with new with address$).ab. 


3 


L2 


Li 


networkS.ab. 


57180 


Li 



END OF SEARCH HISTORY 



h eb bgeee e b fffech 



Freeform Search 



Page 1 of 1 



Freeform Search 



Database: 



Term: 



US Pre-Grant Publication Full-Text Database 



US Patents Full-Text Database 



US OCR Full-Text Database 
EPO Abstracts Database 
JPO Abstracts Database 
Derwent World Patents Index 
IBM Technical Disclosure Bulletins 



Ll and ( (replace$ or updat$) with (address$ adj2 |^ 
compar$)) ■ 



Display: |10 | Documents in Display Format : |KWIC | Starting with Number |l 
Generate: O Hit List ® Hit Count O Side by Side O Image 



[Search 1 1 Clear,? ; FT"? Interrupt 



Search History 



DATE: Wednesday, February 16, 2005 Printable Copy Create Case 

Set Name Query Hit Count Set Name 

side by side result set 

DB=USPT; PLUR=YES; OP=ADJ 

L2 Ll and ((replace$ or updat$) with (address$ adj2 compar$)) 27 L2 

U routing.ab. 7186 Ll 

END OF^SEARGHHISTQRY 



h eb bgeeefe bch 



f ff e ch 



WEST Refine Search 



Page 1 of 2 



Refine Search 



Search Results - 



Term 


Documents 


SIG 


4790 


SIGS 


156 


(7 AND SIG).USPT. 


5 


(L7 AND SIG).USPT. 


5 



Database: 



I US Pre-Grant Publication Full-Text Database 



US Patents Full-Text Database 



US OCR Full-Text Database 
EPO Abstracts Database 
JPO Abstracts Database 
Derwent World Patents Index 
IBM Technical Disclosure Bulletins 



Search: 



Lll 



m 



Igleara 



Search History 



DATE: Wednesday, February 16, 2005 Printable Copy Create Case 



Set Name Query - Hit Count Set Name 

side by side result set 

DB=USPT; PLUR=YES; OP=ADJ 



Lll 


L7 and SIG 


5 


Lll 


LIO 


L7 and SIG 


5 


LIO 


L9 


L8 and (compar$ adj3 address$) 


2 


L9 


L8 


L7 and ((replac$ or updat$) with addressS) 


15 


L8 


L7 


L4 or L5 


74 


L7 


L6 


L3 and PNNIATM 


0 


L6 


L5 


L3 and PNNI 


74 


L5 


L4 


L3 and (PTSE or PTSP) 


11 


L4 


L3 


709/$. eels. 


17245 


L3 


L2 


LI and ((replace$ or updat$) with (address$ adj2 comparS)) 


27 


L2 


LI 


routing.ab. 


7186 


Li 



h eb bcgb eech 



WEST Refine Search Page 2 of 2 



END OF SEARCH HISTORY 



h e b 



b eg b e e ch 



Record List Display 



Page 1 of 10 



Hit List 







1 »08 


1 


1 -EMM 





Search Results - Record(s) 1 through 6 of 6 returned. 



□ 1. Document ID: US 6788649 Bl 

L14: Entry 1 of 6 File: USPT Sep 7, 2004 



DOCUMENT-IDENTIFIER: US 6788649 Bl 

TITLE: Method and apparatus for supporting ATM services in an intelligent network 
Brief Summary Text (8) : 

The signaling protocol is defined in ATM standards according to network interfaces. 
The ATM Forum has defined, among other interfaces, a public User-Network Interface 
("UNI"), defined as the interface between an ATM user and a public ATM network; a 
private User-Network Interface, defined as the interface between an ATM user and a 
private ATM network; and, a Private Network-Network Interface ( " PNNI " ) defined as 
the network-network interface between two private networks or switching systems. 
Various features of ATM are enabled by signaling messages defined by these 
interfaces . 

Detailed Description Text (20) : 

Additionally NGIN supports ATM one number services capability including: 1) Find 
me/Follow me wherein given an address that is assigned to a particular subscriber, 
that subscriber may change the destination associated with that address . The 
feature that would be provided with this capability enables a subscriber to receive 
calls as they move locations; and, 2) Alternate routing wherein if a destination is 
unavailable, it is possible to specify an alternate destination. 

Detailed Description Text (56) : 

In addition to the foregoing, NGIN is capable of supporting the following 
functional requirements relating to Vnet service including, but not limited to: 1) 
the ability for national and international dialed VNET numbers to be screened; 2) 
the ability to translate VNET dialed number digits to a format (such as outpulse 
digits) that an NGS switch will understand, in order to support national or 
international DAL and Direct Distance Dialing (DDD) terminations; 3) the ability to 
allow international VNET calls to have a predetermined format including, for 
example, three (3) digits for identifying the country and the seven (7) digits 
indicating the private network number; 4) the capability to change the termination 
address obtained from the originating party and reroute the call to an alternate 
termination (Call Rerouting/Alternate Routing) . The alternate termination may be a 
NANP DDD number, a Vnet termination, a mobile phone number, an international 
termination number IDDD, an ACD or a voice/fax mail system, etc. and any change 
made may be transparent to the calling party if necessary; 5) providing NXX 
Exchange Routing involving the use of the exchange code, and the Area ID (retrieved 
by using the customers NXX Exchange routing plan id) , instead of the normal 
geographic lookup information, when performing termination translation; 6) 
providing the ability for VNET calls to be screened at the corporate, network, or 
access (originating switch, carrier) levels (Range Privilege Screening); 7) the 
ability to provide Remote Access to VNET, i.e., to designate 800, 900, and global 
freephone numbers for remote access to VNET. When such a number is dialed, a VNET 
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dial tone is provided, as well as the nature of permissible VNET addresses, and how 
many supplementary digits to collect; 8) ability to provide a Route Data Calls 
capability, i.e., the ability for customers to order all digital routing for their 
VNET service. A digital route indicator (uses switch 56 path) is sent to the switch 
along with the route translation; 9) the support of private dialing plans of any 
business or residential customer. Currently, VNET customers may create their own 
network dialing plans, e.g., 4-12 digit national numbers dialing plans, and 7-15 
digit international dialing plans may be defined; 10) the ability to perform VNET 
Card Validation, e.g., via an ADF message; 11) the ability to perform a Vnet work 
at home voice services, i.e., employees who work at home may be assigned a business 
number to their home phone. When they make business phone calls, they may use the 
Vnet service by dialing a *feature code prior to the Vnet number. The NGIN Vnet SLP 
accesses the Vnet dialing plan of the customer; translates the number to the Vnet 
termination; and charges the call to the Vnet business customer automatically. When 
an incoming call is received, a distinctive ringing may be applied to alert the 
user of a business call; and, 12) the capability to deactivate VNET cards and 
enable a user to deactivate VNET cards. 

Current US Cross Reference Classification ( 6) : 
709/202 



R*vi4w C lasi if icatio n Date Rsfersnce 



n 2. Document ID: US 6724724 Bl 

L14: Entry 2 of 6 File: USPT ■ Apr 20, 2004 



DOCUMENT-IDENTIFIER: US 6724724 Bl 

** See image for Certificate of Correction ** 

TITLE: System and method for resolving an electronic address 

Brief Summary Text (9) : 

Each router 18, 22 typically maintains a table of address translations, such as the 
translation of device 22 's X.25 address to device 22 's TCP/IP address. These 
addresses are typically hard coded into the routers 18-20. Accordingly, if an 
address for a device changes, then each router 18-20 that includes that device's 
address will typically need to be accessed and the address will have to be changed. 
Since it is fairly common for a network to have its address scheme changed, it may 
be substantially time consuming to ensure that each router that contained each of 
the changed addresses is accessed and updated. Additionally, the process of 
individually changing an address in all the routers that maintain that address may 
be error prone. 

Brief Summary Text (10) : 

It would be desirable to have an address resolution system and method that allows 
dynamic changes to addresses and avoid the need to access each router containing 
the address to change that address . The present invention addresses such a need. 

Detailed Description Text (20) : 

If no translation is required, then device B is directly contacted (step 206) . If, 
however, the route to device B does require translation, then a name resolution 
service, such as a domain name server (DNS) is contacted (step 208) . The DNS which 
is contacted by the router may be a DNS local to the router, or a specific DNS 
identified in the router's routing table that contains the information to 
facilitate the address translation. Accordingly, only a relatively small number of 
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DNSs would require updates of changes of addresses in order to dynamically affect 
all routers requesting that address. 

Current US Cross Reference Classification (3) : 
709/230 

Other Reference Publication (3) : 

Dillon, Kevin, " PNNI : Effortless Expansion for ATM Networks", Dialog (R) File 647, 
ATM Forum Bay Networks, Nov. 7, 1998. 



Attaclirnenta 



□ 3. Document ID: US 6606303 Bl 

L14: Entry 3 of 6 



File: USPT 



Aug 12, 2003 



DOCUMENT-IDENTIFIER: US 6606303 Bl 

TITLE: Method and device in a packet switched network 



Brief Summary Text (6) : 

In a private Asynchronous Transfer Mode (ATM) network the PNNI function, as 
specified by the ATM Forum will probably become the chosen function for resource 
management with respect to routing and signalling, and other functions. A part of 
the PNNI is a so called dynamic routing protocol meaning that a node in the network 
will announce and update information regarding its own identity, the resources on 
its outgoing links and in the node, and address reachability, to all neighboring 
nodes. This way, in the end all nodes in the network will have a complete 
hierarchical view of the topology of the network, including its available 
resources . 

Brief Summary Text (7): 

The PNNI protocol is defined for use between private ATM switches and between 
private ATM networks. The abbreviation PNNI stands for either Private Network Node 
Interface or Private Network-to-Network Interface, reflecting these two areas of 
use. PNNI routing is used in a private network of ATM switching systems. PNNI 
includes a routing protocol for distribution of topology information between 
switches and groups of switches. The functions of the PNNI routing protocol 
include, among other things: discovery of neighbours and link and node status, 
synchronization of topology databases, construction of the routing hierarchy, 
transmission of PNNI topology state elements from each node to all other nodes. 

Brief Summary Text (11) : 

To avoid the problems of hop-by-hop routing PNNI uses source routing for all 
connection setup requests. The first node in a peer group selects the entire path 
across that peer group and across all other peer groups for the purpose of reaching 
the destination. The path is encoded as a set of Designated Transit Lists (DTLs) 
explicitly included in the connection setup request. The DTLs specify every node 
used in transit across the peer group and may also specify the logical links to be 
used between the nodes. If a node along the path is unable to follow the DTL for a 
specific connection setup request the node must perform a so called crankback, that 
is, return the connection setup request to the node in which the DTL was created. 

Brief Summary Text (18): 

Routing for connections with multiple performance constraints complicates the 
problem in two ways. First, each link must be described in terms of multiple 
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parameters. Second, the ability of a link to participate in a path depends on the 
requirements of the connection being routed. Having fill topology information and 
status about actual network resources and capacity is necessary to be able to 
compare different link costs with each other in order to build least-cost routes to 
every other destination in the network. The PNNI distributes complete routing 
information to all nodes, making it desirable to use Dijkstra's algorithm, which, 
however can only optimize on one parameter. For example, the path for which the 
delay is minimized may very well have an unacceptably low bandwidth or high delay 
variation, or vice versa. 

Brief Summary Text (30) : 

The parameters used comprise the maximum cell transfer delay (CTD) , the peak-to- 
peak Cell Delay Variation (CDV) , the Available Cell Rate (AvCR) , the Maximum Cell- 
Rate (MCR) and the Cell Loss Ratio (CLR) . An Administrative Weight (AW) may also be 
included. These parameters are specified in the PNNI routing specification, agreed 
by the ATM Forum, and will be explained in somewhat more detail below. 

Brief Summary Text (36) : 

The routing with respect to multiple constraints in a PNNI network environment 
specifically addressing the traffic contracts of the rt-VBR service categories is 
enabled. 



Drawing Description Text (2) : 

FIG. 1 shows schematically a packet switch network with two hierarchical levels 
according to the PNNI protocol . 

Detailed Description Text (2) : 

FIG. 1 is a schematic representation of a packet switch network comprising a number 
of logical nodes and with two hierarchical levels. The lowest level of the PNNI 
hierarchy comprises the logical nodes that are organized into peer groups. The 
nodes in a peer group exchange information with the other nodes in the group, so 
that all nodes in the group have an identical view of the group and of other peer 
groups. Each logical node sees all nodes in its own peer group, but sees every 
other peer group only as a single node. 

Detailed Description Text (11) : 

In PNNI, links are advertised unidirectionally, in the outgoing direction, but 
connections are always bidirectional, both directions using the same route. 
Therefore, the associated total link cost of a bidirectional link takes the network 
resources allocated both directions into consideration when computing the link 
cost . 

Detailed Description Text (39) : 

A routing table is updated when the available resources of a node or link is 
changed or when the address reachability in the network is changed. 

Current US Cross Reference Classification (2) : 
709/241 
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** See image for Certificate of Correction ** 

TITLE: Virtual LAN system 

Brief Summary Text (19): 

On the other hand, in a connection-oriented ATM (asynchronous transfer mode) 
system, development of LAN emulation corresponding to the conventional LAN bridge, 
MPOA for providing a multiprotocol router on LAN emulation, an IP-over-ATM system 
for passing the IP on ATM, an IP-over-RSVP system for passing the RSVP on ATM, an 
IP switching system for switching only the IP on ATM, a 1 -PNNI system for routing 
internet protocols on a private signaling protocol between ATM switches, and ATM- 
native transmission quality guarantee (QoS) technique is also pursued. 

Brief Summary Text (35) : 

When the servers managed in a centralized manner in the network center are accessed 
or overlapped segments across segments are formed, communication traffic across 
layer 2 LAN switch segments increases. Then, a switch called a layer 3 LAN switch 
filtered based on the routing protocol address or the protocol type has been 
developed for floor line concentrators. With the layer 3 LAN switch, layer 3 
virtual network segments based on logically defined protocol addresses 
independently of physical wiring like MAC addresses or ports are formed and may be 
called virtual subnet. Since the layer 3 LAN switch contains a router function, 
traffic across layer 2 subnets can also be directly switched not via the main 
router; subnets rather than flat subnets can be classified according to management 
policy or a fire wall for the routing protocol can be provided for enhancing 
security. If the layer 3 LAN switch is formed in an MPOA system on ATM LAN 
simulation, standardization is not yet complete, thus the layer 3 LAN switch may be 
installed under specifications proper to each vendor and limited transmission 
quality guarantee (QoS) is also provided. A backbone LAN system of routing between 
ATM switches in an I -PNNI system and using a layer 3 LAN switch as the edge LAN 
switch is also developed. 

Detailed Description Text (128) : 

Further, the following constitution can be adopted to the port segment switch in 
the present invention. That is, when the terminal is moved between the ports in one 
switch, or when the terminal is moved between the switches, the switch which is 
over layer 2 of the virtula LAN system on the back born side and connected to the 
expansion port detects the correspondence change of MAC address or network address 
with the microsegment, so that the virtual group agent executes the dynamic 
automatic conf igulation management. 

Detailed Description Text (210) : 

On the other hand, VLAN-IDs may be set independently of internet protocol subnets, 
a plurality of virtual subnets or virtual segments may be set in a router internet 
subnet, or a VLAN virtual subnet or virtual segment may be set across router 
internet subnets. In this case, the LAN switches (local router switch 202 and local 
switches 203a . . . ' which need to execute routing based on VLAN-ID, comprise an 
intranet routing table apart from an internet routing table. In the above-mentioned 
IPv6, a local address and a provider address are separated at the header. A fire 
wall section 213 of the main router 201 has a function of changing an internet IP 
address and an intranet IP address to different addresses. 

Current US Original Classification (1) : 
709/223 

Current US Cross Reference Classification (2) : 
709/243 
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n 5. Document ID: US 6002674 A 

L14: Entry 5 of 6 



File: USPT 



Dec 14, 1999 



DOCUMENT- IDENTIFIER: US 6002674 A 

TITLE: Network control system which uses two timers and updates routing information 



Brief Summary Text (3) : 

The present invention relates to the update of routing control information. In a 
network where a plurality of switches each having an ATM (Asynchronous Transfer 
Mode) interface are interconnected, the switches make SVC (Switched Virtual 
Circuit) connection with each other by referring to the information produced by 
exchanging PNNI routing control packets (Hello packets and PTSP (PNNI Topology 
State Packets) ) . 

Brief Summary Text (5) : 

PNNI (Private Network to Network Interface) Specification VI. 00 (hereafter called 
PNNI ) from The ATM Forum Technical Committee describes the interface via which the 
switches in an ATM network make SVC connections. This PNNI contains information on 
the following: 

Brief Summary Text (6) : 

(a) PNNI routing control packet exchange method and exchange information. 
Brief Summary Text (8) : 

The PNNI specifies that topology information be required for generating routing 
information. The topology information refers to network component information or 
state information on the network components such as lines and switches. This 
information is obtained by exchanging PNNI routing control packets the switches 
within the network. 



Brief Summary Text (11) : 

(b) Routing information is generated when a PNNI routing control packet is received 
Brief - Summary Text ' (12)- ' - - - - - 

(c) Topology information is generated from a received PNNI routing control packet 
and, at a specified interval, routing information is generated. 

Brief Summary Text (14) : 

In case of (a) , a delay in setting up a call from an originating terminal degrades 
the overall system performance. In case of (b) , there is a possibility that a large 
number of PNNI routing control packets are received when a line or a switch in the 
network fails or when a condition (repetitive errors and error recovery processing) 
occurs. This condition causes routing information to be updated frequently, 
affecting the system performance. In case of (c), PNNI routing control packet 
information exchanged in the network is not reflected on the routing information 
immediately. Therefore, when an SVC connection request is received before routing 
information is updated by a PNNI routing control packet, the connection request may 
fail; conversely, when an error is already recovered but the routing information is 
not yet updated accordingly, the connection request may fail. 

Brief Summary Text (17) : 

To achieve this objective, this system has two timers: the first timer sends the 
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time-out signal at a specific interval and the second timer at an interval shorter 
than that of the first timer. The first timer sends the time-out signal at the 
longest interval for updating the routing information when the network is in the 
normal state. The second timer sends the time-out signal at the shortest interval 
for updating the routing information. The second timer generates the time-out 
signal at this interval to prevent a large number of PNNI routing control packets 
from being generated and the system performance from being degraded when a line or 
a switch in the network fails or when a line unbalance condition (repetitive errors 
and error recovery processing) occurs. 

Detailed Description Text (3) : 

The first timer updates routing information immediately when it times out. That is, 
the first timer updates routing information at least once at a specified interval. 
On the other hand, the second timer updates routing information when it times out 
and if the significant-change detection flag is on at that time. This means that 
the interval of the second timer is the shortest interval at which routing 
information is updated. The significant-change detection flag is set to on only 
when a received PNNI routing control packet indicates that the registration of the 
address or the link of a terminal or the link of an ATM switch has been changed. 

Detailed Description Text (4 ) : 

A system in this embodiment generates or updates routing information, not when a 
call request is received from a terminal, but when the first or the second timer 
times out. This eliminates a delay in setting up a call. When the system receives a 
large number of PNNI routing control packets, the system does not have to update a 
large volume of routing information because it updates the information at the 
interval of the second timer. This prevents the overall system performance from 
being degraded. In addition, a significant change, such as a change in terminal or 
ATM switch addresses or a change in link data, is reflected on routing information 
when the second timer times out. This allows a call from a terminal to be connected 
successfully. 

Detailed Description Text (10) : 

The first timer 21 updates the routing information 24 at a specified interval. This 
interval is the longest interval at which the routing information 24 is updated. 
The routing information 24 is updated at least once at this interval even when the 
network is in the stable state (i.e. there is no change in terminal address and 
switch address, and there is no change in link configuration in which the switches 
are connected to each other) . 

Detailed Description Text (11) : 

On the other hand, the second timer 22 updates the routing information 24 at the 
shortest interval. A line failure, a switch failure, or a unbalance condition 
(repetitive errors and error recovery processing) on the network may generate a 
large number of PNNI routing control packets. This in turn causes the routing 
information to be updated often, affecting the overall system performance. The 
second timer 22, the shortest-interval time timer, prevents this condition. 

Detailed Description Text (14): 

The address/link information management module 31 manages the address information 
of the ATM switch 100 and link information denotes link configuration in which the 
switches are connected to each other, and the line speed and transmission delay 
thereon) and sends a PNNI routing control packet containing address information and 
link information to another ATM switch 300. 

Detailed Description Text (15) : 

The topology information management module 32 manages topology information which is 
sent from another ATM switch 300 as PNNI routing control packets. Topology 
information is information on terminal addresses, switch addresses, line 
attributes, status, and so forth. Terminal addresses are those of the terminals 
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(e.g., terminal 200 in FIG. 2) connected to an ATM switch (e.g., ATM switch 100 in 
FIG. 2). Switch addresses are those of the switches (e.g., ATM switch 100 or 
another ATM switch 300) configured in the network. Line attributes and status data 
denotes link configuration in which the switches are connected to each other and so 
forth. The line attributes and status data are stored in the address/link 
information management module 31 as link information. 

Detailed Description Text (16) : 

The topology information management module 32 sends or receives PNNI routing 
control packets to or from another ATM switch 300 over the communication line to 
get topology information on each ATM switch and to keep topology information up to 
date. Topology information which is kept up to date in this manner keeps the ATM 
switch 100 informed of which ATM switches and terminals are available for use. 

Detailed Description Text (17): 

The significant change detection module 33 turns on the flag 33a upon detection of 
a pre-determined state in the network. In this embodiment, the significant change 
detection module 33 turns on the flag 33a (a) when the address information or link 
information of the ATM switch 100 is changed or (b) when a PNNI routing control 
packet indicating that the address information or link information of another ATM 
switch 300 is changed. Note that address information and link information may 
change according to how they are used for control. 

Detailed Description Text (19) : 

The ATM switch 100 exchanges PNNI routing control packets with other ATM switches 
to keep address information and link information .up to date for use as topology 
information. And, based on this topology information, the ATM determines a route to 
each terminal or switch in the network and keeps this routing information as the 
routing information 24. When the ATM receives an SVC connection request, it 
references the routing information 24 to find the best route to the destination 
terminal or switch. 

Current US Cross Reference Classification ( 2 ) : 
709/242 

Other Reference Publication (1) : 

af -pnni -0055 . OOP Letter Ballot, ATM Forum Technical Committee, pp. 36-37, 15-17, 
357-364 and 40. 

CLAIMS : 

2. A network control system which controls switched virtual connection on a 
network, containing a plurality of interconnected switches each having an 
asynchronous transfer mode interface, by referencing routing information generated 
by exchanging PNNI routing control packets, the network control system comprising: 

a significant change detection module setting a significant change detection flag 
to on upon detecting a pre-determined condition on the network; 

a first timer generating a time-out signal at a specific interval; 

a second timer generating a time-out signal at an interval shorter than that of the 
first timer; and 

a routing information update control module having the routing information, 
unconditionally updating corresponding routing information upon receiving the time- 
out signal from the first timer, and updating the routing information upon 
receiving the time-out signal from the second timer only if the significant change 
detection flag is on. 
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n 6. Document ID: US 5828844 A 

L14: Entry 6 of 6 



File: USPT 



Oct 27, 1998 



DOCUMENT-IDENTIFIER: US 5828844 A 
TITLE: Internet NCP over ATM 



Detailed Description Text (5) : 

Although both the IP and ATM routing protocols employed in the Classical IP model 
may determine reachability information for the same hosts, they run independently 
of one another. For example, IP routers run routing protocols such as RIP and OSPF 
exchange reachability information pertinent to IP destinations. Likewise, ATM 
switches run independent protocols such as PNNI to determine ATM network topology 
and address reachability. Typically, separate IP routers and ATM switches are 
provided. In fact, many networking scenarios even employ different IP and ATM 
network topologies. 

Detailed Description Text (14): 

Recently, a single device known as an IP switch has been developed. An IP switch 
integrates a conventional router and ATM switch to route IP over ATM networks much 
more efficiently than in the traditional model, which employs distinct devices. The 
IP over ATM model may be substantially simplified if the router and the ATM switch 
physically reside in the same device, as illustrated in FIG. 3. As previously 
mentioned, when the functionality of an ATM switch and an IP router reside on 
separate devices, the ATM switch does not have knowledge pertaining to routing and 
addressing at the IP layer. In contrast, when the functionality of an ATM switch 
and an IP router are merged onto the same device, it becomes possible, to further 
integrate routing at the IP level into routing at the ATM level. For example, a 
perfect topology match is achieved when a layer two node (an ATM switch) is 
physically integrated into a layer three node (an IP router) . Although this 
configuration does not eliminate the problem of matching an IP address with its 
corresponding ATM address, the elimination of the topological mismatch creates the 
opportunity to use a single routing protocol for routing at both the IP and ATM 
layers. An Illustrative protocol that may serve in this capacity includes I -PNNI 
(see R. Callon, Relationship Between MPOA and I -PNNI, April 1996, ATM Forum 96- 
0352), which has been submitted to the ATM Forum to integrate routing at the IPO 
layer into PNNI. I -PNNI facilitates the bootstrapping and ongoing operation of 
Internet routing protocols and associated packet forwarding protocols over an ATM 
network. 

Detailed Description Text (27): 

The address databases may be implemented in any convenient manner. Two possible 
implementations are a fully distributed implementation and a fully duplicated 
implementation. In the fully distributed approach, each IP switch only maintains' an 
address database for those end-points that access the Internet at that particular 
IP switch. Accordingly, there is no need for synchronization among different 
address databases in different IP switches. For example, when a source end-point 
sends an address query to its IP switch regarding a destination end-point and the 
IP to ATM address correspondence is not found in the queried IP switch, the switch 
will forward the request only to the IP switch responsible for the destination end- 
point. In a fully distributed arrangement, the Internet NCP serves as the master 
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database that stores all provisioned information for the network, including the IP 
to ATM address correspondences. When a change in the address database of an IP 
switch occurs (due to a host disconnecting from the IP switch, for example) , the 
same change is forwarded to the Internet NCP to update the master database. 
Similarly, when the Internet NCP is modified by the service provider or the user, 
the appropriate individual address database (s) within the IP switch (es) will be 
updated accordingly. 

Detailed Description Text (28) : 

If the address databases 56 are configured in a fully-duplicated arrangement, each 
IP switch maintains the database for all the end-points. When a new database entry 
is registered with a given IP switch, that registration is sent to all other IP 
switches. Accordingly, the address databases of all the IP switches are identical. 
That is, while the Internet NCP contains the master copy of the database, each IP 
switch maintains its own complete copy of the database. Similar to the fully 
distributed arrangement, if an IP switch makes a change in its database, the change 
will be reflected in all the other address databases, including the master database 
of the Internet NCP. Likewise, if a change is made to the Internet NCP database, it 
will be reflected in all the other address databases. 

Current US Original Classification (1) : 
709/228 
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